











2018 年 春节 期 间 的 “三 点 钟 无 眠 区 块 链 ” 微 信 群 ， 让 “区 块 链 ”这 个 非常 生硬 的 技术 名 词 走 进 了 大 众 的 视野 。 区 块 链 技术 以 密码 学 、P2P 技 术 、 共 识 机 制 为 技术 基础 ， 结 合 激励 模型 ( 指 公有 链 ) 构建 
了 一 个 开放 可 信 的 运行 环境 ， 被 誉 为 “下 一 代 互 联网 ”和 “价值 互联 网 ”。 






































区 块 链 技术 脱胎 于 比特 币 ， 起 初 应 用 于 加 密 数 字 货币 。 以 太 坊 项 目 采 用 区 块 链 技术 构建 了 一 个 智能 合约 平台 ， 大 家 看 到 了 区 块 链 技术 在 广泛 领域 中 应 用 的 可 能 。 自 2017 年 以 来 ， 区 块 链 技 术 热度 持续 升 
温 。 新 的 区 块 链 项 目 呈 现 暴发 式 的 增长 。 几 乎 每 天 都 会 有 各 种 新 的 区 块 链 项 目 出 现 ， 传 统 互联 网 巨头 们 也 纷纷 参与 这 一 领域 。 尤 其 是 最 近 Facebook 发 布 的 Libra 项 目 更 是 引发 了 全 球 金融 界 和 技术 界 的 瞩 
目 。 可 以 预见 ， 区 块 链 将 在 金融 、 保 险 等 重要 的 商业 场景 中 发 挥 巨大 的 作用 。 





















































































































































Asch ( 阿 希 链 ) 是 国内 早期 的 区 块 链 项 目 之 一 ， 也 是 多 链 架构 和 跨 链 技术 的 早期 探索 者 和 布道 者 。Asch 以 推动 区 块 链 技术 的 应 用 落地 与 DApp 普 及 为 愿景 ， 据 有 安全 、 高 效 和 灵活 低 成 本 的 特点 。Asch 
avaScript 为 开发 语言 ， 以 Node.js 为 运行 环境 。JavaScript 是 近 些 年 来 发 展 最 快 、 拥 有 最 大 社区 的 开发 语言 。 尤 其 是 Node.js 的 出 现 让 JavaScript 从 前 端 专 属 ， 变 成 了 一 个 的 全 栈 语言 ， 使 得 JavaScript 

发 后 端 服务 成 为 可 能 。Nodejs 是 一 个 基于 V8 引擎 的 JavaScript 运 行 时 的 平台 ， 可 轻松 构建 快速 、 可 扩展 的 网 络 应 用 程序 。Nodejs 使 用 事件 驱动 的 非 阻塞 |/O 模 型 ， 使 其 轻 量 级 和 高 效 ， 非 常 适合 在 分 布 式 
备 上 运行 的 数据 密集 型 实时 应 用 程序 。Node.js 平 台 的 特点 和 区 块 链 系 统 的 匹配 度 很 高 。 而 JavaScript 拥 有 易学 易 用 的 特点 。 拥 有 非常 大 的 开发 群体 ， 这 也 是 Asch 相 对 与 使 用 其 他 语言 的 DApp 开 发 平台 非 
重要 的 先天 优势 。 
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本 书 的 作者 团队 包含 了 Asch 跨 链 技术 的 核心 开发 者 、Asch DApp 开 发 者 和 Asch 技 术 社区 的 爱好 者 。 本 书 从 最 基础 的 比特 币 的 原理 开始 ， 详 细 分 析 了 Asch 的 技术 架构 和 实现 细节 。 最 后 用 完整 的 案例 介 
绍 了 Asch 侧 链 DApp 的 开发 方式 。 内 容 完整 翔实 ， 描 述 深入 浅 出 。 尤 其 适合 热爱 JavaScript 技 术 的 区 块 链 技 术 爱 好 者 和 开发 者 。 


























钱 汉 涛 ， 阿 希 链 CTO 


2019 年 7 月 于 北京 

















我 至 今 清晰 地 记得 ， 在 2016 年 5 月 的 一 个 傍晚 ， 吴 延 裔 、 单 青峰 还 有 我 在 北航 大 运 村 一 起 吃 烧烤 的 场景 。 单 青峰 满眼 放 光 地 谈 起 他 最 近 在 做 的 项 目 Asch ( 阿 希 ) ， 向 我 们 解释 了 比特 币 和 区 块 链 的 很 多 
技术 原理 。 我 和 吴 延 毅 当时 听 得 也 很 兴奋 ， 预 感 这 项 技术 未 来 肯定 有 很 大 的 前 景 。 









































在 那 次 聚餐 之 后 ， 我 开始 在 网 上 寻找 相关 的 技术 资料 认真 钻研 ， 终 于 理解 了 什么 是 加 密 算法 、 工 作 量 证 明 、UTXO 等 区 块 链 的 技术 概念 ， 内 心 对 这 项 技术 的 热爱 也 与 日 俱 增 。 后 来 慢 慢 开始 以 社区 成 员 
身份 参与 到 Asch 的 相关 工作 中 来 ， 并 且 最 终 入 职 Asch ， 成 为 一 名 全 职 的 区 块 链 开发 工程 师 。 
























































Asch 始 于 2016 年 年 初 ， 当 时 单 青峰 在 思考 如 何 把 区 块 链 技术 应 用 到 更 广泛 的 场景 中 ， 确 定好 了 一 些 现在 看 来 依然 比较 前 沿 的 解决 方案 。 比 如 ， 考 虑 到 开发 成 本 ， 选 择 了 Javascript 语 言 ， 数 据 库 方 面 选 
择 了 关系 数据 库 ; 出 于 链 的 安全 性 和 性 能 等 方面 的 考虑 ， 采 用 了 侧 链 技术 ， 每 个 应 用 都 是 一 条 独立 的 链 。 应 用 既 可 以 保持 自己 的 独立 性 和 灵活 性 ， 又 能 够 享受 Asch 这 个 生态 带 来 的 便利 。 后 来 ，Asch 又 率先 
在 跨 链 方面 进行 了 探索 ， 并 且 在 国内 非常 早 地 提出 了 跨 链 的 解决 方案 并 实现 了 跨 链 。 
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目前 ， 区 块 链 技 术 依然 在 快速 地 迭代 。Asch 作 为 国内 为 数 不 多 并 且 起 步 较 早 的 专注 于 技术 创新 的 项 目 ， 这 一 路 上 的 实践 经 验 是 值得 总 结 的 ， 因 此 有 了 本 书 。 希 望 本 书 能 够 被 更 多 的 同行 看 到 ， 一 起 交流 
和 促进 区 块 链 技术 在 国内 的 发 展 与 应 用 。 








































































































本 书 用 三 个 部 分 讲解 了 区 块 链 技术 以 及 Asch 的 相关 实践 ， 第 一 部 分 讲解 了 区 块 链 技术 的 基本 概念 ， 并 用 300 行 代码 实现 了 一 个 最 小 的 、 可 运行 的 区 块 链 ; 第 二 部 分 分 析 Asch 的 源码 ， 讲 解 Asch 的 实现 原 
理 ; 第 三 部 分 介绍 了 基于 Asch 的 侧 链 技术 的 DApp 开 发 实战 。 全 书 共有 12 章 ， 其 中 梁 培 利 完成 了 第 1、2、3、4、5、9 章 的 创作 ， 吴 延吉 完成 了 第 6、7、8 章 的 创作 ， 曹 帅 完成 了 第 10、11、12 章 的 创作 。 下 
面 是 各 章 的 内 容 介绍 。 






























































第 一 部 分 “区 块 链 开 发 概述 











第 1 章 “ 自 己 动手 实现 一 个 区 块 链 系统 ” ”这 一 章 讲 解 了 如 何 使 用 300 行 代码 实现 一 个 简单 的 区 块 链 系统 ， 内 容 包括 区 块 和 区 块 链 的 构造 、 工 作 量 证 明 算法 的 实现 以 及 通过 HTTP API 的 方式 提供 与 区 块 
链 的 交互 等 。 通 过 这 章 的 实践 ， 读 者 将 会 对 区 块 链 有 一 个 基本 的 了 解 。 
































第 2 章 “DApp 开 发 简介 ” ”这 一 章 介绍 了 智能 合约 的 基本 概念 以 及 案例 ， 然 后 解释 了 DApp 的 概念 及 特点 。 通 过 这 章 ， 读 者 可 以 对 智能 合约 和 DApp 有 一 个 初步 的 认识 。 


第 二 部 分 “Asch 源 码 解读 ” 























第 3 章 “Asch 一 一 区 块 链 应 用 开发 平台 ”Asch 是 一 个 在 2016 年 就 发 布 主 网 的 区 块 链 应 用 开发 平台 ， 目 的 在 于 降低 区 块 链 技术 应 用 的 门槛 ， 帮 助 企业 和 开发 者 快速 地 构建 基于 区 块 链 的 分 布 式 应 用 
(DApp) ， 只 要 开发 者 会 使 用 JavaScript 以 及 有 一 定 的 开发 经 验 。 该 章 将 会 从 Asch 的 发 展 讲 起 ， 一 直到 Asch 的 架构 解析 。 希 望 读 者 在 读 完 这 章 以 后 可 以 对 Asch 有 一 个 清晰 的 了 解 。 


























































































































第 4 章 “Asch 源 码 概览 ”对 于 区 块 链 项 目 来 说， 核心 代码 开源 是 基本 的 要 求 ， 这 种 情况 也 为 我 们 提供 了 大 量 的 学 习 资源 。 阅 读 项 目 源码 是 深入 了 解 一 个 项 目的 最 好 方式 。 从 这 章 开始 ， 我 们 将 会 一 起 
从 源码 级 别 探索 Asch 的 实现 与 运行 机 制 。 这 章 的 主要 内 容 为 源码 概览 以 及 启动 流程 简介 。 




































































第 5 章 “ 账 户 与 安全 ”区 块 链 的 正常 运转 离 不 开 密 码 学 的 支持 。 正 是 因为 利用 了 安全 的 加 密 算法 ， 区 块 链 上 的 每 一 笔 交 易 和 区 块 的 生产 才 有 了 安全 的 保证 。 这 章 首先 探索 区 块 链 用 到 的 基本 算法 ， 然 后 
基于 Asch 的 源码 来 解释 Asch 里 账户 的 生成 与 运用 。 



























































第 6 章 “ 共 识 机 制 ”共识 机 制 是 一 个 区 块 链 系统 的 灵魂 。 但 是 为 什么 区 块 链 系统 需要 共识 机 制 呢 ? 这 一 章 将 从 天 占 庭 将 军 问题 谈 引 ， 一 直 谈 到 目前 比较 流行 的 DPoS+ PBFT 算 法 ， 来 看 看 共识 机 制 解决 
了 哪些 问题 ， 是 如 何 解决 的 ， 最 后 简单 介绍 了 Asch 的 共识 机 制 实现 。 


















































第 7 章 “ 区 块 ” 区 块 是 组 成 区 块 链 的 基本 单位 。 一 个 区 块 的 产生 、 打 包 交 易 、 验 证 以 及 如 何 添加 到 区 块 链 上 往往 和 这 个 区 块 链 系统 采用 的 共识 机 制 有 关 。 这 章 主要 介绍 阿 希 链 上 区 块 的 锻造 、 验 证 以 及 
添加 区 块 到 链 上 等 流程 。 



























































第 8 章 “ 交 易 ” 交易 的 核心 流程 和 区 块 如 出 一 略 ， 只 不 过 交易 是 更 泛 化 的 概念 ， 含 义 比较 广 ， 可 以 代表 转账 、 投 票 等 类 型 ， 这 章 将 详细 介绍 Asch 交 易 相关 的 流程 。 

















第 9 章 “ 跨 链 实现 ” ”如 今 在 区 块 链 所 面临 的 诸多 问题 中 ， 区 块 链 之 间 的 彼此 隔离 成 为 了 区 块 链 技术 应 用 和 资产 流通 的 阻碍 。 无 论 是 公有 链 还 是 私有 链 ， 跨 链 技术 都 是 实现 价值 互联 网 的 关键 。 跨 链 技术 
巴 区 块 链 技术 从 目前 一 个 个 分 散 的 孤岛 中 分 离 出 来 的 良药 ， 也 是 区 块 链 相互 通信 的 桥梁 。 跨 链 技术 的 必要 性 早已 在 链 圈 达 成 了 共识 。 我 们 将 在 这 章 探 索 Asch 的 跨 链 实现 原理 。 
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第 三 部 分 “DApp 开 发 实战 ” 























第 10 章 “DApp 设 计 与 开发 环境 搭建 ” 这 一 章 介 绍 DApp 开 发 ， 从 DApp 设 计 者 的 角度 ， 阐 述 如 何 从 零 到 一 设计 一 个 DApp， 从 业务 模型 、 经 济 模型 到 数据 模型 三 个 层 
地 理解 区 块 链 应 用 。 


层 介绍 ， 帮 助 我 们 更 深入 
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十 
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第 11 章 “DApp 合 约 开发 与 接口 实现 。 ”这 章 通过 CCTime 项 目 案例 介绍 合约 开发 与 接口 实现 。 通 过 这 章 的 学 习 ， 读 者 可 以 知晓 一 个 DApp 开 发 的 详细 过 程 。 





























第 12 章 “DApp 测 试 ” 前面 的 章节 从 环境 搭建 、 应 用 设计 、 代 码 实现 三 个 部 分 介绍 了 DApp 开 发 的 整体 流程 ， 不 过 我 们 还 缺少 了 很 重要 的 一 环 : 单元 测试 。 这 一 章 将 基于 抽奖 合约 的 整个 测试 流程 代码 
讲解 如 何 对 合约 与 接口 进行 测试 。 



































本 书 所 有 涉及 的 代码 都 是 用 JavaScript 语 言 编写 的 ， 因 此 在 阅读 本 书 之 前 ， 希 望 读者 能 够 对 JavaScript 语 言 有 基本 的 了 解 。 











本 书 偏重 于 实战 ， 因 此 建议 读者 在 阅读 本 书 的 同时 自己 动手 实践 。 本 书 有 三 个 部 分 ， 读 者 可 以 根据 自己 的 需求 选择 阅读 ， 三 个 部 分 之 间 并 没有 太 大 的 依赖 关系 。 读 者 如 果 只 想 了 解 区 块 链 的 基本 原理 ， 
那么 建议 阅读 第 一 部 分 。 读 者 如 果 想 了 解 Asch 是 如 何 实现 的 ， 可 以 阅读 第 二 部 分 。 如 果 读 者 已 经 有 一 定 的 区 块 链 基 础 ， 想 要 开发 DApp， 那 么 可 以 直接 阅读 第 三 部 分 并 动手 实践 。 


















































本 书 的 所 有 代码 可 以 在 https://github.com/AschPlatform/dappbook-code 上 找到 。 
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说 以 此 书 ， 献 给 我 的 父母 、 麦 子 以 及 女儿 ， 我 爱 你 们 。 


由 于 本 书 作者 的 水 平 有 限 ， 书 里 难免 会 出 现 错误 或 者 表述 不 准确 的 地 方 ， 在 此 居 请 读者 批评 指正 。 关 于 本 书 的 任何 问题 ， 读 者 可 以 到 https://github.com/AschPlatform/dappbook-code 提 交 lssue。 
届时 关于 本 书 的 任何 勘误 也 都 会 发 布 在 这 个 仓库 。 也 欢迎 读者 发 送 邮 件 到 我 的 邮箱 liangpeili@foxmail.com， 真 诚 地 欢迎 各 种 意见 和 反馈 。 





梁 培 利 


2019 年 5 月 于 北京 龙 泽 苑 


第 一 部 分 “区 块 链 开发 概述 


: 第 1 章 ”自己 动手 实现 一 个 区 块 链 系 统 


.第 2 章 DApp 开 发 简介 














目前 开发 一 个 区 块 链 应 有 以 下 三 种 方式 : 




















“ 从 零 开始 开发 一 个 区 块 链 的 应 用 。 需 要 实现 的 部 分 主要 包括 : 交易 和 区 块 的 构造 、 加 密 算法 、 共 识 机 制 以 及 P2P 通 信 等 。 这 种 方式 适用 于 有 较 大 创新 的 区 块 链 项 目 ， 可 以 灵活 选择 各 种 算法 。 缺 点 在 于 
开发 周期 长 ， 实 现 难度 大 ， 需 要 有 较 强 的 开发 能 力 才 可 以 实现 。 


“ 如 果 你 只 是 想 利用 区 块 链 的 特性 开发 一 个 应 用 ， 而 不 想 从 头 实 现 一 遍 区 块 链 的 底层 机 制 ， 那 么 可 以 选择 一 个 成 熟 的 区 块 链 应 用 开发 平台 。 这 类 平台 类 似 于 现在 的 云 服 务 平台 ， 一 般 会 提供 开发 工具 以 
及 底层 接口 ， 便 于 开发 者 根据 自己 的 业务 场景 来 编写 区 块 链 应 用 。 


“ 基于 现 有 的 区 块 链 项 目 改 造 。 开 源 是 区 块 链 项 目的 一 贯 风格 ,无论 是 区 块 链 的 鼻祖 比特 币 还 是 目前 非常 火 的 EOS， 其 代码 都 在 GitHub 上 开源 了 。 所 以 可 以 阅读 这 些 开源 项 目的 源 代码 ， 查 看 功能 实现 
以 及 评估 安全 性 等 。 这 也 给 新 的 区 块 链 项 目 开发 者 带 来 了 福音 ， 新 项 目的 开发 者 可 以 拉 取 目前 已 经 开源 的 项 目 ， 然 后 根据 自己 的 需求 进行 改造 (当然 首先 要 满足 对 方 项 目的 开源 协议 ) 。 这 也 是 一 种 快速 开 
始 一 个 区 块 链 项 目的 方法 。 


























本 书 的 第 一 部 分 包含 两 章 ， 在 第 1 章 里 我 们 会 简单 梳理 一 下 从 比特 币 到 区 块 链 的 发 展 历程 。 然 后 用 300 行 代码 实现 了 一 个 简单 的 区 块 链 项 目 ， 内 容 涉及 交易 及 区 块 的 构造 、 挖 矿 以 及 基于 工作 量 证 明 的 共 
识 机 制 等 。 相 信 没 有 任何 开发 区 块 链 基础 的 开发 者 都 可 以 很 快 了 解 区 块 链 项 目的 基础 知识 。 第 2 章 阐 述 了 区 块 链 应 用 里 智能 合约 和 DApp 的 含义 ， 然 后 介绍 了 几 个 主流 区 块 链 应 用 的 开发 平台 。 













































































第 1 章 自己 动手 实现 一 个 区 块 链 系统 












































比特 币 是 近 十 年 才 诞 生 的 新 事物 ， 想 要 进行 区 块 链 开发 ， 需 要 先 了 解 比特 币 以 及 区 块 链 的 发 展 背景 。 本 章 首先 介绍 比特 币 的 诞生 和 发 展 ， 以 及 区 块 链 技术 的 基本 概念 ， 包 括 加 密 哈 希 函 数 、 数 字 签名 、 
共识 机 制 等 ， 希 望 能 够 帮助 读者 快速 了 解 区 块 链 技术 的 知识 背景 。 


























“ 纸 上 得 来 终 觉 浅 ， 绝 知 此 事 要 躬 行 ”。 学 习 区 块 链 的 最 好 方式 就 是 自己 动手 实现 。 有 了 基本 概念 之 后 ,我 们 将 一 起 从 头 开始 实现 一 个 简单 的 区 块 链 系统 ， 包 括 区 块 和 区 块 链 的 构造 、 工 作 量 证 明 算 法 
的 实现 以 及 通过 HTTP API 的 方式 提供 和 区 块 链 进 行 交互 等 。 通 过 自己 动手 实现 一 个 区 块 链 系 统 ， 可 以 对 区 块 链 运 行 的 基本 原理 有 一 个 更 深刻 的 理解 。 












































1.1 从 比特 币 到 区 块 链 


1.1.1 ”比特 币 的 诞生 和 发 
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长 久 以 来 ， 人 们 对 货币 的 普遍 认 知 是 国家 基于 国家 信用 发 行 的 、 固 定 的 、 充 当 一 般 等 价 物 的 商品 。 从 上 个 世纪 开始 ， 无 论 是 经 济 学 界 还 是 极 客 圈 都 已 经 在 探索 数字 货币 的 可 行 性 。 数 字 货币 可 以 不 基于 
国家 来 发 行 ， 完 全 诞生 于 虚拟 世界 。 上 个 世纪 未 ， 陆 续 有 人 提出 了 多 种 数字 货币 的 方案 ， 比 如 Wei Dai 的 “b 一 money” 以 及 Adam Back 的 “hashcash” 等。 他 们 在 数字 货币 的 发 展 道路 上 做 出 了 突破 性 的 
贡献 ， 但 是 他 们 提出 的 方案 依然 不 够 完美 ， 最 后 都 没有 流行 开 来 。 












































2008 年 11 月 。 一 个 署名 为 中 本 聪 的 人 在 一 个 密码 学 的 邮件 组 发 表 了 一 篇 论文 《Bitcoin: A Peer-to-Peer Electronic Cash System》 (如 图 1-1 所 示 ) ， 首 次 提出 了 比特 币 的 概念 。 在 这 篇 论文 中 ， 中 本 

















聪 详细 阐述 了 如 何 使 用 P2P 网 络 以 及 加 密 算法 来 创造 一 种 不 需要 依赖 信任 的 电子 交易 系统 。2009 年 1 月 ， 中 本 聪 发布 并 开源 了 第 一 版 的 比特 币 软件 ， 并 用 该 软件 挖 出 了 第 一 个 区 块 (也 称 为 “ 创 世 区 块 ”) 
并 获得 了 第 一 批 的 挖 矿 奖励 : 50 个 比特 币 ， 比 特 币 的 故事 由 此 正式 拉 开 序幕 。 











Bitcoin: A Peer-to-Peer 上 Electronic Cash System 


Satoshi Nakamoto 
satoshin(@gmx.com 
www.bitcoin.org 


Abstract. A purely peer-to-peer version of electronic cash would allow online 
payments to be sent directly from one party to another without going through a 
financial institution. Digital signatures provide part of the solution, but the main 
benefits are lost if a trusted third party is still required to prevent double-spending. 
We propose a solution to the double-spending problem using a peer-to-peer network. 
The network timestamps transactions by hashing them into an ongoing chain of 
hash-based proof-of-work, forming a record that cannot be changed without redoing 
the proof-of-work. The longest chain not only serves as proof of the sequence of 
events witnessed, but proof that it came from the largest pool of CPU power. As 
long as a majority of CPU power is controlled by nodes that are not cooperating to 
attack the network, they']l generate the longest chain and outpace attackers. The 
network itself requires minimal structure. Messages are broadcast on a best effort 
basis, and nodes can leave and rejoin the network at will, accepting the longest 
proof-of-work chain as proof of what happened while they were gone. 





图 1-1 比特 币 的 白皮书 





比特 币 是 第 一 个 诞生 于 虚拟 世界 并 且 可 以 方便 地 进行 价值 转移 的 真正 数字 货币 。 在 比特 币 这 个 系统 里 ， 资 产 的 改行、 交易 的 确认 等 各 种 规则 是 由 协议 来 约束 的 。 比 特 币 的 发 行 总 量 是 2100 万 枚 ， 但 是 比 
特 币 的 发 行 不 是 由 某 一 个 具体 的 人 或 组 织 控制 的 ， 而 是 交 给 了 所 有 维护 这 个 系统 运行 的 节点 。 不 同 的 节点 之 间 通 过 挖 矿 来 竞争 比特 币 的 发 行 权 ， 新 生产 的 比特 币 可 以 转 入 到 自己 指定 的 账户 。 随 着 挖 矿 节 点 
的 竞争 越 来 越 激 烈 ， 比 特 币 网 络 的 整体 算 力也 越 来 越 高 。 比 特 币 系统 中 引入 了 一 个 根据 当前 全 网 算 力 来 自动 调整 挖 矿 的 机 制 ， 用 于 保证 系统 的 产 块 时 间 维持 在 10 分 钟 左右 。 比 特 币 最 初 的 区 块 奖励 是 每 挖 一 
个 区 块 可 以 获取 50 个 比特 币 ， 比 特 币 的 区 块 高 度 每 增长 21 万 (大概 是 四 年 的 时 间 ) ， 区 块 的 奖励 就 会 减 半 。2018 年 7 月 ， 区 块 奖励 为 每 个 区 块 12.5 个 比特 币 。 










































































比特 币 在 诞生 初期 只 是 作为 一 个 新 鲜 物种 流行 于 极 客 圈 ， 那 时 ， 一 台 普 通 的 笔记 本 就 可 以 参与 到 比特 币 的 挖 矿 过程 中 并 且 有 巨大 的 回报 。 比 特 币 的 价格 从 一 开始 每 个 比特 币 兑换 0.003 美 元 到 2017 年 底 
达到 最 高 2 万 美元 ， 中 间 也 经 历 过 几 次 大 起 大 落 ， 如 图 1-2 所 示 。 
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经 过 近 十 年 的 发 展 ， 比 特 币 目前 已 经 形成 了 完整 的 生态 体系 。 这 个 体系 包括 比特 























献 着 自己 的 资源 ， 发 表 自 己 的 看 法 ， 共 同 推动 着 比特 


1.1 从 比特 币 到 区 块 链 


1.1.1 ”比特 币 的 诞生 和 发 展 





长 久 以 来 ， 人 们 对 货币 的 普遍 认 知 是 国 





6 社区 的 发 展 。 











家 基于 国 

















贡献 ， 但 是 他 们 提出 的 方案 依然 不 够 完美 ， 最 后 者 

















国家 来 发 行 ， 完 全 诞生 于 虚拟 世界 。 上 个 世纪 末 ， 陆 续 有 人 提出 了 多 种 数字 货 f 
没有 流行 开 来 。 





1-2 比特 币 2012 年 以 来 的 价格 走势 (图片 来 自 于 coindesk) 

















6 的 核心 开发 者 (Bitcoin Core) 、 矿 池 、 矿 机 生产 商 、 交 易 所 、 钱 包 以 及 用 户 等 。 他 们 在 比特 币 这 个 开放 的 社区 中 贡 














家 信用 发 行 的 、 固 定 的 、 充 当 一 般 等 价 物 的 商品 。 从 上 个 世纪 开始 ， 无 论 是 经 济 学 界 还 是 极 客 圈 都 已 经 在 探索 数字 货币 的 可 行 性 。 数 字 货币 可 以 不 基于 
5 的 方案 ， 比 如 Wei Dai 的 “b 一 money” 以 及 Adam Back 的 “hashcash” 等 。 他 们 在 数字 货币 的 发 展 道路 上 做 出 了 突破 性 的 











2008 年 11 月 。 一 个 署名 为 中 本 聪 的 人 在 一 个 密码 学 的 邮件 组 发 表 了 一 篇 论文 《Bitcoin: A Peer-to-Peer Electronic Cash System》 (如 图 1-1 所 示 ) ， 首 次 提出 了 比特 币 的 概念 。 在 这 篇 论文 中 ， 中 本 
聪 详细 阐述 了 如 何 使 用 P2P 网 络 以 及 加 密 算 法 来 创 

















造 一 科 


不 需要 依赖 信任 的 电子 交易 系统 。2009 生 




















FE1 月 ， 中 本 聪 发 布 并 开源 了 第 一 版 的 比特 币 软件 ， 并 上 











并 获得 了 第 一 批 的 挖 矿 奖励 : 50 个 比特 





5， 比特 条 








和 的 故 奸 


由 此 正式 拉 开 序幕 。 








该 软件 挖 出 了 第 一 个 区 块 (也 称 为 “ 创 世 区 块 ”)， 





Bitcoin: A Peer-to-Peer Electronic Cash System 


Satoshi Nakamoto 
satoshin(@gmx.com 
www.bitcoin.org 


Abstract. A purely peer-to-peer version of electronic cash would allow online 
payments to be sent directly from one party to another without going through a 
financial institution. Digital signatures provide part of the solution, but the main 
benefits are lost if a trusted third party is still required to prevent double-spending. 
We propose a solution to the double-spending problem using a peer-to-peer network. 
The network timestamps transactions by hashing them into an ongoing chain of 
hash-based proof-of-work, forming a record that cannot be changed without redoing 
the proof-of-work. The longest chain not only serves as proof of the sequence of 
events witnessed, but proof that it came from the largest pool of CPU power. As 
long as a majority of CPU power is controlled by nodes that are not cooperating to 
attack the network, they'll generate the longest chain and outpace attackers. The 
network itself requires minimal structure. Messages are broadcast on a best effort 
basis, and nodes can leave and rejoin the network at will, accepting the longest 
proof-of-work chain as proof of what happened while they were gone. 





图 1-1 比特 币 的 白皮书 





比特 币 是 第 一 个 诞生 于 虚拟 世界 并 且 可 以 方便 地 进行 价值 转移 的 真正 数字 货币 。 在 比特 币 这 个 系统 里 ， 资 产 的 改行、 交易 的 确认 等 各 种 规则 是 由 协议 来 约束 的 。 比 特 币 的 发 行 总 量 是 2100 万 枚 ， 但 是 比 
特 币 的 发 行 不 是 由 某 一 个 具体 的 人 或 组 织 控制 的 ， 而 是 交 给 了 所 有 维护 这 个 系统 运行 的 节点 。 不 同 的 节点 之 间 通 过 挖 矿 来 竞争 比特 币 的 发 行 权 ， 新 生产 的 比特 币 可 以 转 入 到 自己 指定 的 账户 。 随 着 挖 矿 节 点 
的 竞争 越 来 越 激 烈 ， 比 特 币 网 络 的 整体 算 力也 越 来 越 高 。 比 特 币 系统 中 引入 了 一 个 根据 当前 全 网 算 力 来 自动 调整 挖 矿 的 机 制 ， 用 于 保证 系统 的 产 块 时 间 维持 在 10 分 钟 左右 。 比 特 币 最 初 的 区 块 奖励 是 每 挖 一 
个 区 块 可 以 获取 50 个 比特 币 ， 比 特 币 的 区 块 高 度 每 增长 21 万 (大 概 是 四 年 的 时 间 ) ， 区 块 的 奖励 就 会 减 半 。2018 年 7 月 ， 区 块 奖励 为 每 个 区 块 12.5 个 比特 币 。 






























































比特 币 在 诞生 初期 只 是 作为 一 个 新 鲜 物种 流行 于 极 客 圈 ， 那 时 ， 一 台 普 通 的 笔记 本 就 可 以 参与 到 比特 币 的 挖 矿 过程 中 并 且 有 巨大 的 回报 。 比 特 币 的 价格 从 一 开始 每 个 比特 币 兑换 0.003 美 元 到 2017 年 底 
达到 最 高 2 万 美元 ， 中 间 也 经 历 过 几 次 大 起 大 落 ， 如 图 1-2 所 示 。 
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1-2 ”比特 币 2012 年 以 来 的 价格 走势 (图 片 来 自 于 coindesk) 














经 过 近 十 年 的 发 展 ， 比 特 币 目前 已 经 形成 了 完整 的 生态 体系 。 这 个 体系 包括 比特 币 的 核心 开发 者 (Bitcoin Core) 、 矿 池 、 矿 机 生产 商 、 交 易 所 、 钱 包 以 及 用 户 等 。 他 们 在 比特 币 这 个 开放 的 社区 中 贡 
献 着 自己 的 资源 ， 发 表 自 己 的 看 法 ， 共 同 推动 着 比特 币 社区 的 发 展 。 









































1.1.2 ”区 块 链 





比特 币 是 第 一 个 真正 意义 上 的 加 密 数 字 货 币 ， 也 是 一 个 价值 传递 的 网 络 。 然 而 它 也 面临 着 很 多 问题 : 交易 并 发 量 过 低 (扩容 前 比特 币 每 秒 仅 支持 7 笔 交 易 ， 也 就 是 TPS 为 7) ， 确 认 速 度 慢 (一般 认 为 经 
过 6 次 确认 是 安全 的 ， 大 概 需要 一 个 小 时 ) ， 浪 费 电力 。 根 据 权 威 统计 ， 目 前 维持 比特 币 系统 运转 所 耗费 的 电力 相当 于 一 个 中 型 国家 的 消耗 。 


Oi 


比特 币 的 TPS 是 如 何 计算 出 来 的 ? 在 比特 币 系 统 里 ， 最 小 的 交易 包含 了 一 个 输入 和 两 个 输出 (包括 收 款 人 以 及 找 零 地 址 ) 的 P2PKH 类 型 的 交易 。P2PKH 的 输入 为 148 个 字 节 ， 输 出 为 34 个 字 节 。 每 笔 交易 
的 额外 开销 (overhead) 又 占 了 10 个 字 节 。 所 以 在 比特 币 系统 里 一 笔 最 小 交易 的 长 度 为 148+234+10=226 个 字 节 。 比 特 币 的 区 块 大 小 限制 为 1M 字 节 ， 也 就 是 1000000 字 节 。 考 虑 极限 情况 下 ， 一 个 区 块 里 所 有 
的 交易 都 是 这 种 最 小 的 交易 ， 而 比特 币 是 每 10 分 钟 生产 一 个 新 的 区 块 ， 因 此 比特 币 每 秒 最 多 可 以 处 理 的 交易 为 1000000/226/6010=7.37 TPS。 目 前 比特 币 系统 里 交易 的 平均 大 小 为 520 字 节 ， 所 以 实际 比特 币 
的 TPS 为 3 左右 。 



































其 实 ， 在 中 本 聪 的 白皮书 中 并 没有 “区 块 链 ” 这 个 词 ， 中 本 聪 提出 的 是 一 个 基于 哈 希 链表 的 数据 结构 ， 可 以 用 于 解决 支付 中 的 双 花 问题 (Double spend problem) 。 因 为 比特 币 底层 技术 有 巨大 的 应 
潜力 ， 所 以 人 们 将 比特 币 的 底层 技术 抽 离 出 来 ， 并 给 它 起 了 一 个 好 听 的 名 字 : 区 块 链 。 区 块 链 技术 是 一 种 分 布 式 不 可 算 改 的 加 密 数 据 库 技术 ， 主 要 解决 的 是 去 中 心 化 节点 间 的 数据 一 致 性 问题 ， 并 且 融 入 
了 通 证 (Token) 的 经 济 激励 机 制 。 可 以 大 大 增强 数据 的 安全 度 和 可 信 度 。 



















































































区 块 链 技术 主要 包括 以 下 几 个 部 分 。 








1. 加 密 哈 希 函数 


我 们 都 知道 ， 一 个 函数 可 以 接收 一 个 或 若干 个 输入 值 ， 然 后 经 函数 运算 产生 一 个 或 若干 个 输出 值 。 哈 希 函数 满足 所 有 下 列 条 件 : 








“ 接收 任意 长 度 的 字符 串 作 为 输入 。 
“ 产生 一 个 国定 长 度 的 输出 值 。 
“ 计算 时 间 在 合理 范围 内 。 


只 要 满足 上 述 条 件 ， 一 个 函数 就 可 以 称 为 哈 希 函数 。 举 个 简单 的 例子 : 取 模 运算 ， 任 意 数字 对 10 取 模 后 得 到 的 结果 都 是 0 ~ 9 之 间 的 一 个 数字 ， 那 么 取 模 运算 就 可 以 认为 是 一 个 哈 希 函 数 。 











目前 用 于 比特 币 等 数字 货币 的 哈 希 函 数 则 是 加 密 哈 希 函 数 。 加 密 哈 希 函数 除了 拥有 上 述 哈 希 函数 的 三 个 特点 外 ， 还 有 着 更 为 独特 的 特性 : 无 碰撞 性 、 隐 藏 性、 结果 随机 性 ， 下 面 分 别 解释 。 




















(1) 无 碰撞 性 








无 三 撞 性 分 为 强 无 碰撞 性 和 弱 无 碰撞 性 。 强 无 碰撞 性 的 意思 是 ， 对 于 一 个 哈 希 函 数 H， 我 们 无 法 找到 两 个 不 同 的 x 和 y 值 ， 使 得 H (x) =H (y) 。 弱 无 碰撞 性 则 是 ， 对 于 一 个 哈 希 函 数 H 以 及 输入 x 值 ， 无 
法 找到 另外 一 个 y 值 ， 使 得 H (x) =H (y) 。 























无 硕 撞 性 并 不 是 真正 的 “无 ”碰撞 ， 碰 撞 是 肯定 存在 的 ， 这 里 强调 的 是 寻找 碰撞 的 难度 。 我 们 以 比特 币 中 使 用 到 的 哈 希 函数 SHA256 为 例 ， 它 的 输出 值 为 256 位 ， 因 此 结果 只 有 2256 种 可 能 ， 但 是 输入 值 
却 可 以 有 无 限 种 可 能 。 现 在 就 有 一 种 必然 能 找到 碰撞 的 办 法 : 我 们 首先 找到 2256+ 1 个 不 同 的 值 ， 分 别 计算 出 它们 的 哈 希 值 ， 那 结果 集 里 必然 有 重复 的 值 ， 这 样 就 会 发 现 一 次 碰撞 了 。 但 是 这 种 方法 的 可 行 性 
怎样 呢 ? 假设 把 全 世界 所 有 的 计算 设备 集合 起 来 ， 从 宇宙 诞生 的 时 刻 到 现在 一 直 不 停 地 运算 ， 能 够 找到 一 次 碰撞 的 概率 和 下 一 秒 钟 地 球 被 陨石 撞击 而 毁灭 的 概率 一 致 。 既 然 你 读 到 了 这 里 ， 那 就 说 明 地 球 毁 
灭 没有 发 生 ， 也 就 是 没有 碰撞 发 生 。 









































现在 还 没有 一 种 加 密 哈 希 函 数 在 数学 上 被 证 明 是 严格 无 碰撞 性 的 ， 现 在 市 面 上 提 到 的 无 碰撞 性 ， 一 般 认 为 是 目前 除了 暴力 破解 之 外 没有 其 他 的 途径 能 够 更 快 地 找到 碰撞 而 已 。 以 前 也 有 曾经 被 认为 是 无 
碰撞 性 的 哈 希 函数 后 来 找到 了 破解 方案 的 案例 。 比 如 MD5 哈 希 算法 。 比 特 币 使 用 的 SHA256 哈 希 算 法 目前 也 被 认为 是 无 碰撞 性 的 ， 但 是 不 排除 以 后 被 破解 的 可 能 。 









































无 碰撞 性 有 什么 应 用 呢 ? 一 个 比较 常见 的 就 是 消息 摘要 (Message Digest) 。 消 息 摘要 是 指针 对 任意 长 度 的 输入 ， 通 过 加 密 哈 希 函 数 运算 后 得 到 的 哈 希 值 。 以 现在 常用 的 哈 希 算法 MD5 为 例 ， 其 运算 
示例 如 下 : 




















liangpeili@LiangXiaoxin:~$ echo 'liang' | md5sum 
ca75d8d934e4ae05a7146fb68f99f059 - 
liangpeili@LiangXiaoxin:~$ echo 'aschplatform' | md5sum 


150fa3630db1d8£576d1266176f6e0f7 - 
liangpeili@LiangXiaoxin:~$ md5sum mongodb-linux-x86 64-3.4.6.tgz 
7b32958579f2a92e5d0471lael9c0f5eb mongodb-linux-x86 64-3.4.6.tgz 





为 无 碰撞 性 的 存在 ， 我 们 可 以 认为 这 个 字符 串 能 唯一 地 代表 输入 值 。 








可 见 输入 任何 长 度 的 字符 串 ， 得 到 的 结果 都 是 固定 长 度 的 随机 字符 





U0 


























我 们 平时 在 互联 网 上 下 载 软件 时 ， 如 何 确定 我 们 下 载 的 这 个 软件 和 网 站 上 的 软件 就 是 同一 个 呢 ? 这 时 消息 摘要 就 可 以 发 挥 作 用 了 。 例 如 ， 有 的 网 站 在 下 载 软件 时 提供 该 软件 的 md5sum 值 ， 那 么 我 们 在 
下 载 完 该 软件 时 ， 就 可 以 手工 计算 一 遍 该 软件 的 md5sum 值 ， 然 后 和 网 站 上 的 值 进行 对 比 ， 只 要 两 个 数值 一 致 ， 就 可 以 说 明 我 们 下 载 的 软件 是 完整 无 误 的 。 

















(2) 隐藏 性 





给 定 H (x) ， 无 法 推测 出 x 的 值 。 不 仅 无 法 推测 出 x 的 值 ， 也 不 能 推测 出 关于 x 的 任何 特点 ， 比 如 奇偶 性 等 。 





(3) 结果 随机 性 
无 论 x 值 是 否 相近 ， 经 过 哈 希 运 算 后 得 出 的 H (x) 都 是 完全 随机 的 。 


这 个 特点 是 说 ， 哪 怕 输 入 值 x 的 长 度 很 长 ， 同 时 另 一 个 输入 值 x 和 x 值 只 有 一 位 不 同 ， 那 它们 经 过 哈 希 函数 H 运 算 后 得 到 的 结果 没有 任何 的 相关 性 ， 就 像 输入 了 两 个 完全 不 同 的 x 值 一 样 。 
继续 以 md5sum 值 为 例 : 


liangpeili@LiangXiaoxin:~$ echo 'aschplatform' | md5sum 
150fa3630db1dq8f576d1266176f6e0f7 一 
liangpeili@LiangXiaoxin:~$ echo 'aschplatforml' | md5sum 
e915a617b2301631ec1l4d1lca2c093c63 - 
liangpeili@LiangXiaoxin:~$ echo 'aschplatform2' | md5sum 
bbb9d830f4a5d47051f9fdl9cb0fc75e  - 











从 上 面 的 程序 中 可 以 看 出 ， 即 使 只 改变 一 个 很 小 的 值 ， 经 过 哈 希 运算 后 的 结果 也 会 有 很 大 的 不 同 。 
































这 个 特性 有 什么 作用 呢 ? 如 果 我 们 针对 特定 的 结果 值 H (x) ， 想 找到 一 个 符合 条 件 的 输入 值 x:， 那 么 除了 暴力 尝试 之 外 没有 其 他 办 法 。 继 续 以 SHA256 为 例 ， 它 的 输出 结果 长 度 为 256 位 ， 如 果 我 们 想 找 
到 这 样 的 一 个 x 值 ， 使 得 它 经 过 SHA256 运 算 后 ， 结 果 的 第 一 位 是 0， 求 解 这 样 的 x 值 的 期 望 次 数 为 2， 那 如 果 想 要 得 到 连续 10 位 为 0 的 哈 希 值 呢 ? 期 望 计算 次 数 就 是 210 了 。 通 过 调整 结果 范围 ， 我 们 就 可 以 对 
计算 次 数 (也 可 以 认为 是 结果 难度 ) 进行 调整 ， 这 也 是 比特 币 调整 难度 值 的 原理 。 















































使 用 Python 实现 的 挖 矿 算法 如 下 : 


#!/usr/bin/env Python 
#coding:utf-8 
# example of proof-of-work algorithm 


import hashlib 
import time 


max nonce = 2 ** 32 # 4 billion 
def proof of work(header, difficulty bits): 


# calculate the difficulty target 
target = 2 ** (256-difficulty bits) 


for nonce in xrange (max_nonce) : 
hash result = hashlib.sha256 (str (header) +str (nonce) ) .hexdigest () 


# check if this is a valid result, below the target 
if long (hash result, 16) < target: 
Print ("Success with nonce %d" % nonce) 
print ("Hash is %s" % hash result) 
return (hash result, nonce) 
Print ("Failed after %d (max nonce) tries" % nonce) 
return nonce 3 


if name = main : 


nonce = 0 
hash result = "'" 


# difficult from 0 to 15 bits 
for difficulty bits in xrange (16): 


diftficulty = 2 ** difficulty bits 
print ("Difficulty: %ld (%d bits)" %(difficulty, difficulty bits)) 


print ("Starting searchhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/...") 


# checkpoint the current time 
start time = time.time() 


# make a new block which includes the hash from the previous block 
# we fack a block of transactions - just a string 


new block = 'test block with transactions' + hash result 
# find a valid nonce for the new block 
(hash result, nonce) = proof of work(new block, difficulty bits) 


# checkpoint how long it took to find a result 
end time = time.time() 


elapsed time = end time - start time 


print ("Elapsed Time: %.4f seconds" % elapsed time) 
if elapsed time > 0: 
# estimate the hashes per second 


hash power = float (long (nonce) /elapsed time) 
print ("Hashing Power: %1ld hashes Per second" % hash power) 


2 数字 签名 











在 现实 工作 和 生活 中 ， 我 们 使 用 签名 的 方式 表达 了 对 一 份 文件 的 认可 ， 其 他 人 可 以 识别 出 你 的 签名 并 且 无 法 伪造 你 的 签名 。 数 字 签 名 就 是 对 现实 签名 的 一 种 电子 实现 ， 它 不 仅 可 以 完全 达到 现实 签名 的 
特点 ， 甚 至 能 做 得 更 好 。 常 用 的 数字 签名 算法 有 RSA (Rivest-Shamir-Adleman Scheme) 、DSS (Digital Signature Standard) 等 。 比 特 币 使 用 ECDSA (椭圆 曲线 数字 签名 算法 ) 来 生成 账户 的 公私 钥 
以 及 对 交易 和 区 块 进行 验证 (参见 后 面 5.1.2 节 ) 。 



























































数字 签名 的 工作 原理 如 下 所 示 : 














1) Alice 生 成 一 对 密 铀 ， 一 个 是 sk (signing key) ， 是 非 公开 的 ; 另 一 个 是 vk (verification key) ， 是 公开 的 。 这 一 对 密 钥 同时 生成 ， 并 且 在 数学 上 是 相互 关联 的 ， 同 时 ， 根 据 vk 无 法 推测 出 关于 sk 的 
任何 信息 。 











2) 数字 签名 算法 接收 两 个 输入 : 信息 M 和 sk， 生 成 一 个 数字 签名 Sm。 

















3) 验证 函数 接收 信息 M、Sm 以 及 vk 作 为 输入 ， 返 回 的 结果 是 yes 或 者 no。 这 一 步 的 目的 是 为 了 验证 你 看 到 的 针对 信息 M 的 数字 签名 确实 是 由 Alice 的 sk 来 签发 的 ， 用 于 确认 信息 与 签名 是 否 相符 。 























与 手写 签名 不 同 ， 手 写 签名 基本 都 是 相似 的 ， 但 是 数字 签名 却 受 输 入 影响 很 大 。 对 输入 的 轻微 改变 都 会 产生 一 个 完全 不 同 的 数字 签名 。 一 般 不 会 直接 对 信息 进行 数字 签名 ， 而 是 对 信息 的 哈 希 值 进行 签 
名 。 由 加 密 哈 希 函 数 的 无 碰撞 性 可 知 ， 这 样 和 对 原 信息 进行 签名 一 样 安 全 。 


3. 共 识 机 制 

















区 块 链 可 以 看 做 是 一 本 记录 所 有 交易 的 分 布 式 公开 账簿 ， 而 区 块 链 中 每 个 节点 都 是 对 等 的 。 这 就 带 来 一 个 问题 : 谁 有 权 往 这 个 账本 录入 数据 ? 如 果 有 好 几 个 节点 同时 对 区 块 链 进行 数据 写 入 ， 最 终 以 谁 
的 为 准 ? 这 就 是 在 分 布 式 网 络 中 如 何 保持 数据 一 致 性 的 问题 。 共 识 机 制 是 指 在 一 个 分 布 式 的 网 络 中 ， 让 各 个 参与 网 络 的 节点 达成 数据 上 的 一 致 性 。 在 区 块 链 中 ， 共 识 机 制 的 作用 还 包括 区 块 生产 、 区 块 验证 
以 及 系统 的 经 济 激励 等 功能 。 













































































不 同 的 共识 机 制 适用 于 不 同 的 应 用 场景 ， 以 下 是 常用 的 共识 机 制 及 其 适用 的 应 用 场景 介绍 : 









































“ 工作 量 证 明 (Proof of Work，POW) 一 一 比特 币 使 用 的 就 是 工作 量 证 明 的 共识 机 制 。 在 这 种 机 制 里 ， 任 何 拥有 计算 能 力 的 设备 都 可 以 参与 竞争 区 块 的 生产 ， 系 统 会 根据 当前 全 网 的 算 力 动态 调整 难度 
值 ， 来 保证 平均 每 10 分 钟 网 络 将 根据 后 续 区 块 的 态度 来 决定 认可 哪个 区 块 。 一 般 来 说 ， 一 笔 交 易 在 经 过 6 次 确认 【( 约 1 个 小 时 ) 后 被 认为 是 比较 安全 而 且 不 可 逆 的 。 中 本 聪 在 设计 比特 币 时 ， 使 用 工作 量 证 明 
机 制 背后 的 核心 思想 是 “one cpu one vote”， 期 望 能 够 把 比特 币 设计 成 一 个 完全 去 中 心 化 的 系统 ， 任 何人 都 可 以 使 用 电脑 等 终端 参与 进来 。 虽 然后 来 由 于 矿 池 的 出 现 ， 使 得 比特 币 系 统 的 算 力 比较 集中 ， 但 
目前 工作 量 证 明 机 制 仍然 被 认为 是 最 适合 公 链 的 共识 机 制 。 


* 股权 证 明 (Proof of Stake，POS) 





股权 证 明 机 制 于 2013 年 被 提出 ， 最 早 应 用 于 Peercoin 中 。 在 工作 量 证 明 机 制 中 ， 生 产 区 块 的 概率 和 你 拥有 的 算 力 成 正比 。 相 应 的 ， 在 股权 证 明 机 制 中 ， 生 产 区 块 
的 难度 和 你 在 该 系统 中 占有 的 股权 成 正比 。 在 股权 证 明 机 制 中 ， 一 个 区 块 的 生产 过 程 为 : 节点 通过 保证 金 ( 代 币 、 资 产 、 名 声 等 具备 价值 属性 的 物品 即 可 ) 来 对 赌 一 个 合法 的 区 块 会 成 为 新 的 区 块 ， 其 收益 
为 抵押 资本 的 利息 和 交易 服务 费 。 提 供 的 保证 金 越 多 ， 获 得 记 账 权 的 概率 就 越 大 。 一 旦 生产 了 一 个 新 的 区 块 ， 节 点 就 可 以 获得 相应 的 收益 。 股 权证 明 机 制 的 目标 是 为 了 解决 工作 量 证 明 机 制 里 大 量 能 源 被 浪 
费 的 问题 。 恶 意 参 与 者 存在 保证 金 被 罚没 的 风险 。 


“ 授权 股权 证 明 (Delegated Proof of Stake，DPOS) 一 一 工作 量 证 明和 股权 证 明 机 制 虽 然 都 可 以 解决 区 块 链 数 据 的 一 致 性 问题 ,但 正如 上 面 提 到 的 工作 量 证 明 机 制 存 在 算 力 集中 ( 矿 池 ) 的 问题 ， 而 股权 
证 明 机 制 根据 保证 金 的 数量 来 调节 生产 区 块 难度 的 方式 则 会 导致 “ 马 太 效应 ”的 出 现 ， 也 就 是 拥有 大 量 代 币 的 账户 权利 会 越 来 越 大 ， 有 可 能 支配 记 账 权 。 为 了 解决 前 两 者 的 问题 ， 后 来 又 有 人 提出 了 基于 股 
权证 明 机 制 的 改进 算法 一 授权 股权 证 明 机 制 。 在 这 种 共识 机 制 里 ， 系 统 中 的 每 个 持 币 用 户 都 可 以 投票 给 某 些 代表 ， 最 终 得 票 率 在 前 101 名 的 代表 可 以 获得 系统 的 记 账 权 。 这 些 代表 按照 既定 时 间 来 锻造 区 
块 ， 并 且 获 取 锻 造 区 块 的 收益 。 授 权 股 权证 明 机 制 既 可 以 提高 共识 的 效率 〈 相 比较 比特 币 每 10 分 钟 生产 一 个 区 块 ， 这 种 机 制 可 以 实现 10 秒 以 内 生产 一 个 区 块 ) ， 又 避免 了 能 源 的 浪费 和 马 太 效应 ， 因 此 成 为 
了 很 多 新 兴 公 链 (比如 EOS) 的 选择 。 


4 交易 的 区 块 链 





























在 比特 币 网 络 中 ， 每 笔 交易 完成 后 ， 这 笔 交易 会 广播 到 比特 币 的 P2P 网 络 。 矿 工 不 仅 能 够 接收 到 这 笔 交 易 ， 而 且 还 能 接收 到 相同 时 间 段 内 其 他 的 所 有 未 被 记录 的 交易 。 矿 工 的 工作 就 是 把 这 些 所 有 交易 
打包 成 一 个 交易 区 块 。 具 体 的 过 程 是 : 


























1) 矿工 会 把 这 些 交 易 记录 两 两 配对 ， 通 过 默 克 尔 树 计算 出 根 节 点 的 值 。 





2) 根 节点 和 上 一 个 区 块 的 哈 希 值 结合 ， 作 为 一 个 Challenge String， 供 矿工 作为 工作 量 证 明 的 输入 值 。 


Wu 


矿工 完成 工作 量 证 明 ， 并 把 proof 公 开 出 去 供 其 他 节点 验证 。 同 时 在 第 一 条 记录 (这 条 记录 也 称 为 coinbase transaction) 里 给 自己 分 配 挖 矿 奖励 。 























4) 其 他 节点 验证 通过 ， 该 区 块 作为 新 区 块 加 入 到 区 块 链 中 。 





5) 矿工 也 可 以 收集 其 他 交易 记录 里 的 交易 费 分 配给 自己 。 
































比特 币 的 诞生 和 区 块 链 技术 的 不 断 发 展 给 我 们 巨大 的 想象 力 。 目 前 ， 互 联网 完成 了 信息 的 传递 ， 而 区 块 链 技术 或 许可 以 为 互联 网 带 来 价值 的 传递 。 区 块 链 技术 的 基础 设施 、 应 用 场景 或 六 
时 间 才 可 以 发 展 到 目前 互联 网 技术 的 水 平 ， 但 是 区 块 链 技术 的 潜力 却 不 容 小 虎 。 














世 





还 需要 一 定 的 











1.2 用 300 行 代码 开发 一 个 区 块 链 系统 











本 节 使 用 Nodejs 来 实现 一 个 简单 的 区 块 链 系 统 ， 只 需 300 行 代码 。 











1.2.1 区 块 和 区 块 链 的 创建 














区 块 链 是 把 区 块 用 哈 希 指针 连接 起 来 的 链条 ， 区 块 是 其 中 的 基本 单位 。 这 里 我 们 从 设计 一 个 区 块 的 数据 结构 开始 。 


























1. 创 建 区 块 




















区 块 是 构建 区 块 链 的 基本 单位 ， 一 个 区 块 至 少 要 包含 以 下 信息 。 








“ index: 区 块 在 区 块 链 中 的 位 置 。 

' timestampb: 区 块 产生 的 时 间 。 

“ transactions: 区 块 包含 的 交易 。 

. previousHash: 前 一 个 区 块 的 Hash 值 。 


“hash: 当前 区 块 的 Hash 值 。 











其 中 ， 最 后 两 个 属性 previousHash 和 hash 是 区 块 链 的 精华 所 在 ， 区 块 链 的 不 可 纂 改 特性 正 是 由 这 两 个 属性 来 保证 的 。 





根据 上 面 的 信息 ， 我 们 来 创建 一 个 Block 类 : 





const SHA256 = require('crypto-js 


class Block { 

// 构造 函数 

constructor (index, timestamp) 
this.index = index; 
this.timestamp = timestamp; 
this .transactions = []; 
this.previousHash = ''; 
this 


{ 


} 
// 计算 区 块 的 哈 希 值 
calculateHash() { 


/sha256'); 


.hash = this.calculateHash (); 


return SHA256 (this.index + this.previousHash + this.timestamp + JSON.stringify (this.transactions) + this.nonce) .toString () 7 


} 
// 添加 新 的 交易 到 当前 区 块 


addNewTransaction (sender, recipient, amount) 


this.transactions.push({ 
senger, 
recipient, 
amount 


1) 
} 
// 查看 当前 区 块 里 的 交易 信息 


getTransactions () { 
return this.transactions; 
} 


. 

















在 上 面 的 Block 类 的 实现 中 ， 我 们 实 

















了 crypto-js 里 的 SHA256 来 作为 区 块 的 哈 希 算法 ， 这 也 是 比特 币 中 使 


























的 哈 希 算法 。transactions 是 一 系列 交易 对 象 的 列表 ， 其 中 包含 的 每 笔 交易 的 格式 为 : 





sender: sender, 
recipient: recipient, 
amount: amount 


i 





另外 我 们 给 Block 类 添加 了 三 个 方法 : 





2. 创 建 区 块 链 


区 块 构建 完成 后 ， 下 一 步 就 是 考虑 如 何 把 








calculateHash、addNewTransaction、get-Transactions， 分 别 





来 计 








区 块 组 装 成 一 个 区 块 链 了 。 














和 








要 考虑 到 创 世 





区 块 链 就 是 一 个 链表 ， 链 表 中 的 每 个 元 素 都 是 一 个 


TD 


区 块 链 














一 个 创 世 


区 块 的 生成 。 以 下 是 代码 示例 : 


算 当 前 





区 块 哈 希 、 


增加 新 交易 到 当前 














区 块 、 获 取 当 前 








区 块 所 有 交易 。 


区 块 (Genesis Block) 来 进行 初始 化 ， 这 也 是 区 块 链 的 第 一 个 区 块 ， 需 要 手工 生成 。 在 我 们 创建 Blockchain 类 时 ， 


本 
毅 





class Blockchain { 
constructor() { 
this.chain = [this.createGenes 


. 

// 创建 创始 区 块 

createGenesisBlock() { 
Const genesisBlock = new Block 
genesisBlock.previousHash = '0 
genesisBlock.addNewTransaction 
return genesisBlock; 


// 获取 最 新 区 块 
getLatestBlock() { 
return this.chain[this.chain.l 


{ 

// 添加 区 块 到 区 块 链 

addBlock (newBlock) { 
newBlock.previousHash = this.g 
newBlock.hash = newBlock.calcu 
this.chain.push (newBlock); 


¢ 
// 验证 当前 区 块 链 是 否 有 效 
isChainValid() { 
for (let i = 1; i < this.chain 
Const currentBlock = this .ch: 
Const previousBlock = this.c 


// 验证 当前 


是 否 


区 块 的 hash 是 否 





J 


isBlock()]; 


(0, "01/10/2017"); 
让 
('Leo', 'Janice', 


520); 


ength - 1]; 


etLatestBlock () .hash; 
lateHash (); 


.length; i++){ 
ain[il]; 
hainiti = 1]; 


E 确 


if (currentBlock.hash !== currentBlock.calculateHash()){ 


return false; 


} 


// 验证 当前 区 块 的 previousHash 
if(currentBlock.previousHash 
return false; 
} 
return true; 
} 
} 





是 否 等 于 上 一 个 区 块 的 hash 
!== previousBlock.hash) { 





在 Blockchain 这 个 类 中 ， 我 们 实现 了 一 个 创建 创 世 








区 块 的 方法 。 由 于 创 世 





区 块 中 并 没有 前 一 个 区 块 ， 

















个 代 币 ， 由 此 产生 了 一 笔 交易 并 记录 到 创 世 
区 块 和 往 区 块 链 中 添加 新 的 区 块 。 最 后 一 个 
分 对 此 场景 进行 验证 。 




















3. 对 区 块 链 进行 测试 





区 块 中 。 最 后 我 们 把 这 个 创 世 
isChainValid 方 法 是 通过 3 





区 块 添加 到 构造 函数 中 ， 这 样 
验证 区 块 的 哈 希 值 来 














区 块 链 就 包含 一 个 创 世 


此 previousHash 设 置 为 0。 另 外 假定 这 一 天 是 Leo 和 Janice 的 结婚 纪 . 
区 块 了 。 方 法 getLatestBlock 和 addBlock 含 义 比 较 明显 ， 含 义 分 别 是 获取 最 新 








人 








1 














签证 整个 区 块 链 是 否 有 效 ， 如 果 已 经 添加 到 区 块 链 的 区 块 数据 被 算 改 ， 那 么 该 方法 则 返 








回 











到 现在 为 止 ， 我 们 已 经 实现 了 一 个 最 简 
特性 。 





单 的 





区 块 链 了 。 在 这 一 部 分 ， 我 们 会 对 创建 的 





区 块 链 进行 测试 。 方 法 是 向 





我 们 先 创建 一 个 名 字 叫 作 testCoin 的 区 块 链 。 使 

















Blockchain 类 新 建 一 个 对 象 ， 此 时 它 应 该 只 包含 创 世 区 块 : 





，Leo 给 Janice 转 账 520 











区 块 链 中 添加 两 个 完整 的 





区 块 ， 并 且 通 过 尝试 修改 





区 块 内 容 来 展示 





区 块 链 的 不 可 算 改 的 


为 false。 我 们 会 在 下 一 部 





const testCoin = new Blockchain () 7 


console.1og (JSON.stringify (testCoin.chain, undefined, 2)); 


运行 该 程序 ， 结 果 为 : 








[ 
{ 
"index": 0, 
"timestamp": "01/10/2017", 


"transactions": [ 


"sender": "Leo", 
"recipient": "Janice", 
"amount": "520" 


. 


’ 
"previousHash": "0", 
"hash": "23975e8996cd37311c7fd0907f9b2511c3bf23cf9c9147cca329dec76d7b544e" 








然后 ， 我 们 新 建 两 个 区 块 里 都 包含 一 笔 交 易 。 然 后 把 这 两 个 区 块 依次 添加 到 testCoin 这 个 区 块 链 上 : 











区 块 ， 每 个 











blockl = new Block('1', '02/10/2017'); 


blockl .addNewTransaction('Alice', 'Bob', 500); 
testCoin.addBlock (block1) 7 

block2 = new Block('2', '03/10/2017'); 
block2.addNewTransaction('Jack', 'David', 1000); 


testCoin.addBlock (block2); 
console.1og (JSON.stringify (testCoin.chain, undefined, 2)); 








可 以 得 到 以 下 结果 : 
[ 
{ 

"index": 0, 

"timestamp": "01/10/2017", 

"transactions": [ 

{ 
"sender":; "Leo", 
"recipient": "Janice", 
"amount": 520 
. 

]y 

"previousHash": "0"， 

"hash": "23975e8996cd37311c7fd0907f9b2511c3bf23cf9c9147cca329qec76d7b544e" 

}, 

mindexn: "1", 

"timestamp": "02/10/2017", 

"transactions": [ 
"sender": "Alice", 
"recipient": "Bob", 
"amount": 500 


. 


]， 
"previousHash": "23975e8996cd37311c7fd0907f9b2511c3bf23cf9c9147cca329dec76d7b544e", 
"hash": "32b96fa0bba9a7353e67498d822fb0c1f89c307098295c288459cb44dbc5d0f1" 


"index": "2", 
"timestamp": "03/10/2017", 
"transactions": [ 
和 
"sender": "Jack", 
"recipient": "David", 
"amount": 1000 
} 


]， 
"previousHash": "32b96fa0bba9a7353e67498d822fb0c1f89c307098295c288459cb44dqbc5d0f1"， 
"hash": "3a0b9a0471bb474f7560968f2f05ff93306cfc26be7f854a36dc4fea92018db2" 








testCoin 现 在 包含 三 个 区 块 ， 除 了 一 个 创 世 区 块 以 外 ， 剩 下 的 两 个 区 块 是 我 们 刚刚 添加 的 。 注 意 每 一 个 区 块 的 previousHash 








此 时 我 们 使 














isChainValid 方 法 可 以 验证 该 区 块 链 的 有 效 性 。console.log (testCoin.isChainValid () ) 的 返回 








区 块 链 的 防 篡改 性 体现 在 哪里 呢 ? 我 们 先 来 修改 第 一 个 区 块 的 交易 。 在 第 一 个 











属性 是 否 正确 地 指向 了 前 一 个 





结果 为 true。 











区 块 中 ，Alice 向 Bob 转 账 500 元 ， 假 设 Alice 后 悔 了 ， 她 只 想 付 100 元 给 Bob， 于 是 修改 交易 信息 如 下 : 





block1.transactions[0] .amount = 100; 
console.1og (blockl.getTransactions () ) 





Alice 查 看 区 块 链 的 交易 信息 ， 发 现 已 经 改 成 了 100 元 ， 放 心地 走 了 。Bob 看 到 后 ， 发 现 交易 遭 到 了 篡改 。 于 是 Bob 开 始 
































isChainValid 方 法 来 证 明 目 前 的 testCoin 是 无 效 的 。 因 为 testCoin.isChainValid () 返回 值 为 false。 但 是 testCoin. 
易 的 内 容 ， 这 个 时 候 block1 的 哈 希 值 肯定 和 通过 之 前 交易 计算 出 的 

















if (currentBlock.hash !== currentBlock.calculateHash()){ 
return false; 


} 


谷 希 值 是 不 同 的 。 这 两 个 值 的 不 同 会 触发 isChainValid 返 


信 集 证 据 ， 他 怎么 证 明 block1 的 那 笔 交易 是 被 人 为 自 改 后 的 交易 呢 ?Bob 可 以 调 
nValid () 为 什么 会 返回 false 呢 ? 我 们 来 看 一 下 背后 的 逻辑 : 首先 Alice 修 改 了 交 
为 false， 也 就 是 如 下 代码 实现 的 功能 : 


isChai 











回 























既然 如 此 ，Alice 在 修改 交易 内 容 的 同时 修改 block1 的 hash 不 就 可 以 了 吗 ?”Alice 可 以 继续 纂 改 其 他 的 区 块 内 容 : 














blockl .transactions [0] .amount = 1007 
block1.hash = blockl.calculateHash () 7 
Console.1og (testCoin.isChainValid () ) 











这 样 的 话 ， 最 后 的 结果 依然 是 false。 为 什么 呢 ?是 因为 下 面 这 段 代 码 : 























if (currentBlock.previousHash !== previousBlock.hash){ 
return false; 


} 





每 一 个 区 块 都 存储 了 上 一 个 
发 现 的 情况 下 算 改 已 有 数据 的 。 在 真实 的 
性 。 


区 块 的 哈 希 值 ， 只 修改 一 个 区 块 是 不 够 的 ， 还 需要 修改 下 一 个 
区 块 链 项 目 中 ， 修 改 一 个 该 区 块 之 后 的 所 有 





























1.2.2 ”工作 量 证 明 











上 节 实 现 的 区 块 链 系统 还 比较 简单 ， 并 且 没有 解决 电子 货币 系统 中 需 











解决 的 “双重 支付 ”问题 。 要 想 维持 整个 系统 健康 运转 ， 


区 块 存储 的 previousHash。 如 果 我 们 已 经 安全 地 存储 了 block2 的 哈 希 值 ， 那 无 论 如 何 Alice 都 是 不 可 能 在 不 被 
区 块 ， 这 也 是 无 法 办 到 的 村 











情 。 





区 块 链 的 这 个 “ 哈 希 指针 ”的 特性 ,保证 了 





区 块 链 数 据 的 不 可 篡改 





需要 在 系统 中 设计 一 定 的 经 济 激励 机 制 。 在 比特 币 体系 中 ， 中 本 聪 就 设 





计 了 一 个 “工作 量 证 明 ” 的 机 制 ， 解 决 了 系统 里 的 经 济 激励 问题 以 及 双重 支付 问题 。 下 面 我 们 介绍 工作 量 证 明 算 法 的 原理 和 实现 。 











1. 工 作 量 证 明 算 法 














一 个 健康 运行 的 区 块 链 系统 随时 会 产生 交易 ， 我 们 需要 有 服务 器 进行 以 下 工作 : 定时 把 一 个 时 间 段 (比特 币 是 10 分 钟 ，Asch 是 10 秒 ) 的 交易 打包 到 一 个 区 块 ， 并 且 添 加 到 现 有 的 区 块 链 中 。 但 是 一 个 区 
块 链 系统 中 可 能 有 很 多 台 服 务 器 ， 究 竟 是 以 哪 台 服务 器 打包 的 区 块 为 准 呢 ? 为 了 解决 这 个 问题 ， 比 特 币 中 采用 了 一 种 叫做 工作 量 证 明 的 算法 来 决定 采用 哪 一 台 服 务 器 打包 的 区 块 并 且 给 予 相应 的 奖励 。 





















































工作 量 证 明 算 法 可 以 简单 地 描述 为 : 在 一 个 时 间 段 同时 有 多 台 服 务 器 对 这 一 段 时 间 的 交易 进行 打包 ， 打 包 完成 后 连带 区 块 Header 信 息 一 起 经 过 SHA256 算 法 进行 运算 。 在 区 块头 以 及 奖励 交易 coinbase 
里 各 有 一 个 变量 nonce， 如 果 运 算 的 结果 不 符合 难度 值 ( 稍 后 会 解释 这 个 概念 ) 要 求 ， 那 么 就 调整 nonce 的 值 继续 运 算 。 如 果 有 某 台 服务 器 率先 计算 出 了 符合 难度 值 的 区 块 ， 那 么 它 可 以 广播 这 个 区 块 。 
他 服务 器 验证 没 问题 后 就 可 以 添加 到 现 有 区 块 链 上 ， 然 后 大 家 再 一 起 竞争 下 一 个 区 块 。 这 个 过 程 也 称 为 “ 挖 矿 ”。 





















































工作 量 证 明 算 法 采用 了 哈 希 算法 SHA256， 这 种 算法 的 特点 是 难以 通过 运算 得 到 特定 的 结果 ， 但 是 一 旦 计算 出 来 合适 的 结果 后 则 很 容易 验证 。 在 比特 币 系统 里 ， 找 到 一 个 符合 难度 要 求 的 区 块 需要 耗费 
10 分 钟 左右 ， 但 是 验证 它 是 否 有 效 却 是 瞬间 的 事 。 在 下 一 节 的 代码 实现 里 我 们 会 看 到 这 一 点 。 



























































举 一 个 简单 的 例子 : 假设 有 一 群 人 玩 一 个 扔 硬币 游戏 ， 每 个 人 有 十 枚 硬币 ， 依 次 扔 完 十 枚 硬币 ， 最 后 看 十 站 中 的 正面 和 反面 的 排序 结果 。 由 于 最 后 的 结果 是 有 顺序 的 ， 结 果 总 有 210 种 可 能 。 现 在 有 个 规 
定 ， 在 一 轮 游戏 中 ， 谁 先 扔 出 了 前 4 枚 硬币 都 是 正面 的 结果 ， 谁 就 可 以 得 到 奖励 。 于 是 大 家 都 开始 扔 十 枚 硬币 并 统计 结果 。 前 四 枚 都 是 正面 的 可 能 性 有 26 种 ， 因 此 一 个 人 能 获取 该 结果 的 期 望 尝试 次 数 为 
24。 如 果 规 定 正面 的 个 数 越 多 ， 那 么 每 个 人 的 尝试 次 数 就 会 越 多 ， 而 这 里 的 个 数 就 是 难度 。 如 果 玩 游戏 的 人 和 逐渐 增多 ， 那 我 们 就 可 以 要 求 结果 的 前 6 个 、 前 8 个 是 正面 ， 这 样 每 轮 游 戏 的 时 间 依 然 差 不 多 。 这 
也 是 为 什么 比特 币 的 算 力 大 增 ， 而 依然 能 保持 平均 每 10 分 钟 产 生 一 个 区 块 的 原因 。 


































































































上 面 阐述 了 什么 是 工作 量 证 明 ， 那 如 何 把 它 添加 到 我 们 的 区 块 链 应 用 中 呢 ? 








任何 一 个 数据 经 过 SHA256 运 算 后 都 会 得 到 长 度 为 256 位 的 二 进 制 数 值 ， 我 们 可 以 通过 调整 最 开始 的 部 分 连续 0 的 个 数 作为 “难度 值 ”。 比 如 我 们 要 求 最 后 的 区 块 经 过 SHA256 运 算 后 第 一 位 为 0， 那 么 平 
均 每 两 次 运算 就 会 得 到 一 个 这 样 的 结果 。 但 是 如 果 我 们 要 求 连续 10 位 都 是 0， 那 就 需要 平均 计算 210 次 才能 得 到 一 次 这 样 的 结果 了 。 系统 可 以 通过 调整 计算 结果 里 连续 0 的 个 数 来 达成 调整 难度 的 目标 。 






































我 们 在 区 块 的 头 信息 中 添加 一 个 变量 nonce。 通 过 不 停 地 调节 nonce 的 值 来 重新 计算 整个 区 块 的 哈 希 值 ， 直 到 计算 的 结果 满足 难度 要 求 。 











2. 工 作 量 证 明 的 代码 实现 

















基于 上 节 的 概念 ， 我 们 开始 改造 现在 的 区 块 链 应 用 。 首 先 在 Block 类 添加 一 个 honce 变 量 : 





class Block { 
constructor (index, timestamp) { 

this.index = index; 
this.timestamp = timestamp; 
this .transactions = []; 
this.previousHash = "'; 
this.hash = this.calculateHash (); 
this.nonce = 0; 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 





然后 在 Block 类 中 添加 一 个 mineBlock 方 法 : 





mineBlock (difficulty) { 
console.log(‘Mining block ${this.index} ); 
while (this.hash.substring(0, difficulty) !== Array(difficulty + 1).join("0")) { 
this.noncet+; 
this.hash = this.calculateHash(); 


i 
Console.1og("BLOCK MINED: " + this.hash); 


方法 mineBlock 就 是 根据 难度 值 来 寻找 nonce， 只 有 找到 合适 的 nonce 之 后 才 可 以 提交 区 块 。 这 里 的 difficulty 指 的 是 结果 里 从 开头 连续 为 0 的 个 数 。 如 果 计 算出 来 的 哈 希 值 不 符合 要 求 ， 那 么 nonce 加 
1， 然 后 重新 计算 区 块 的 哈 希 值 。 

















于 是 ， 我 们 在 Blockchain 类 里 定义 一 个 难度 值 : 





constructor() { 
this.chain = [this.createGenesisBlock()]; 
this.difficulty = 2; 

} 








把 挖 矿 的 过 程 应 用 到 添加 区 块 到 区 块 链 的 过 程 中 : 























addBlock (newBlock) { 
newBlock.previousHash = this.getLatestBlock() .hash; 
newBlock.mineBlock (this.difficulty); 
this.chain.push (newBlock); 

* 








到 此 为 止 ， 我 们 对 应 用 的 改造 就 完成 了 。 下 面 对 这 部 分 添加 后 的 代码 进行 测试 。 














我 们 先 只 添加 一 个 区 块 : 





const testCoin = new BlLockchain () 7 

blockl = new Block('1', '02/10/2017'); 

blockl .addNewTransaction('Alice', 'Bob', 500); 
testCoin.addBlock (block1); 


Console.1og (block1) 





Mining block 1 
BLOCK MINED: 005fed00324fcbelf0ab1703afe94e45a99e197a7df142e669444687f9513e57 


Block { 
index: !10 
timestamp: '02/10/2017', 
transactions: [ { sender: 'Alice', recipient: 'Bob', amount: 500 } ] 


PreviousHash: '31lbl5cc32d6772f237dcf298d5b7a2417£298f40ce6d8d5fbe07958141ldf7a4c', 
hash: '005fed00324fcbe1f0ab1703afe94e45a99e197a7df142e669444687f9513e577， 
nonce: 419 } 

















注意 那个 honce 值 以 及 hash 值 。nonce 值 表明 了 计算 次 数 ，hash 值 是 最 后 得 到 的 结果 。 这 次 我 们 设置 的 难度 值 为 2， 期 望 计算 次 数 是 28 次 (hash 里 一 个 字符 代表 4 位 ) 。 如 果 把 难度 值 改 成 3 呢 ? 运算 结 
果 为 : 





Mining block 1 
BLOCK MINED: 000b7f1l7beaf58bc8fea996a9fed11103ed27ad6963818b87d89a440cd9757b5 


Block { 
index: '1', 
timestamp: '02/10/2017', 
transactions: [ { sender: 'Alice', recipient: 'Bob', amount: 500 } ]， 


previousHash: '31bl5cc32d6772£f237dcf298d5b7a2417f298f40ce6d8d5fbe07958141df7a4c', 
hash: '000b7f1l7beaf58bc8fea996a9fed11103ed27ad6d63818b87d89a440cd9757b5"， 
nonce: 4848 } 








可 以 看 到 ， 计 算 的 次 数 增加 了 。 随 着 难度 值 增 大 ，CPU 计 算 的 次 数 也 会 呈 指 数 级 增加 ， 相 应 耗费 的 时 间 也 就 越 长 。 


1.2.3 ”提供 和 区 块 链 进行 交互 的 API 


1. 挖 矿 奖励 


在 实现 相关 API 之 前 ， 我 们 首先 来 看 一 下 什么 是 挖 矿 奖励 。 





上 面 介绍 了 挖 矿 的 原理 并 且 实 现 了 工作 量 证 明 算 法 ， 可 是 服务 器 为 什么 愿意 贡献 自己 的 CPU 资源 去 打包 区 块 呢 ? 答案 就 是 挖 矿 时 有 一 个 奖励 机 制 。 矿 工 在 打包 一 个 时 间 段 的 交易 后 ， 会 在 区 块 的 第 一 笔 
交易 的 位 置 创建 一 笔 新 的 交易 。 这 笔 交易 没有 发 送 人 ， 接 收入 可 以 设 为 任何 人 (一 般 设置 为 自己 的 地 址 ) ， 奖 励 的 数额 是 多 少 呢 ? 目 前 比特 币 矿工 每 打包 一 个 区 块 的 奖励 是 12.5 个 BTC。 这 笔 奖励 交易 是 由 
系统 保证 的 ， 并 且 可 以 通过 任何 一 个 其 他 节点 的 验证 。 



























































这 里 面 有 几 个 问题 。 首 先 ， 奖 励 金额 的 问题 。 比 特 币 刚 开 始 发 行 时 ， 每 个 区 块 的 奖励 是 50BTC， 其 后 每 隔 四 年 时 间 减 半 ，2018 年 7 月 已 经 是 12.5 个 BTC 了 。 其 次 ， 矿 工 能 否 创建 多 笔 奖励 交易 或 者 加 大 奖 
励 金额 ?矿工 当然 可 以 这 么 干 ， 但 是 这 么 做 以 后 广播 出 去 的 区 块 是 无 法 通过 其 他 节点 验证 的 。 其 他 节点 收 到 区 块 后 会 进行 合法 性 验证 ， 如 果 不 符合 系统 的 规则 就 会 丢弃 该 区 块 ， 而 该 区 块 最 终 也 不 会 被 添加 
到 区 块 链 中 。 









































2. 代 码 重 构 


为 了 把 我 们 当前 的 代码 改造 成 适合 通过 API 对 外 提供 的 形式 ， 需 要 做 以 下 几 个 处 理 : 

















1) 在 Blockchain 类 中 添加 属性 currentTransactions， 用 于 收集 最 新 交易 ， 并 且 准 备 打包 到 下 一 个 区 块 中 : 

















constructor() { 
this.chain = [this.createGenesisBlock()]; 
this.difficulty = 3; 
this.currentTransactions = []; 


} 





2) 把 Block 类 中 的 addNewTransaction 方 法 移 到 Blockchain 类 里 。 





3) 把 Block 类 和 Blockchain 类 输出 (export) ， 将 app.js 重 命名 为 blockchain.js。 


最 后 的 blockchain.js 内 容 应 该 为 : 





const SHA256 = require('crypto-js/sha256'); 


// 区 块 类 
class Block { 
constructor (index, timestamp) { 

this.index = index; 
this.timestamp = timestamp; 
this.transactions = []; 
this.previousHash = ''; 
this.hash = this.calculateHash (); 
this.nonce = 0; 


} 


calculateHash() { 
return SHA256 (this.index + this.previousHash + this.timestamp + JSON.stringify (this.transactions) + this.nonce) .toString(); 


} 


mineBlock (difficulty) { 
console.log(‘Mining block ${this.index} ); 
while (this.hash.substring(0, difficulty) !== Array (difficulty + 1).join("0")) { 
this.noncet+; 
this.hash = this.calculateHash(); 
§ 
Console.1og("BLOCK MINED: " + this.hash); 


getTransactions() { 
return this.transactions; 
} 
} 


// 区 块 链 类 
class Blockchain { 
constructor() { 
this.chain = [this.createGenesisBlock()]; 
this.difficulty = 3; 
this.currentTransactions = []; 


} 


addNewTransaction (sender, recipient, amount) { 
this.currentTransactions.push ({ 
sender, 
recipient, 
amount 
1D); 
» 


createGenesisBlock() { 
Const genesisBlock = new Block(0, "01/10/2017"); 
genesisBlock.previousHash = '0'; 
genesisBlock.transactions.push({ 
sender: 'Leo', 
recipient: 'Janice', 
amount: 520 
)¥ 
return genesisBlock; 


} 


getLatestBlock() { 
return this.chain[this.chain.length - 1]; 


} 


addBlock (newBlock) { 
newBlock.previousHash = this.getLatestBlock () .hash; 
newBlock.mineBlock (this.difficulty); 
this.chain.push (newBlock); 

$ 


isChainValid() { 
for (let i = 1; i < this.chain.lengthy i++){ 
Const currentBlock = this.chain[i]; 
const previousBlock = this.chain[i -~ 1]; 


if(currentBlock.hash !== currentBlock.calculateHash()){ 
return false; 


} 


if(currentBlock.previousHash !== previousBlock.hash){ 
return false; 
} 
} 
return true; 
‘ 
} 


module.exports = { 
Block, 
Blockchain 

} 





注意 ， 上 面 顺便 修改 了 Blockchain 里 的 方法 createGenesisBlock 的 代码 。 
3. 使 用 Express 提 供 API 服 务 


为 了 能 够 提供 API 服 务 ， 这 里 我 们 采用 Nodejs 中 最 流行 的 Express 框 架 。 区 块 链 对 外 提供 以 下 三 个 接口 : 











“ POST/transactions/new: 添加 新 的 交易 ， 格 式 为 JSON。 
“ GET/mine: 将 目前 的 交易 打包 到 新 的 区 块 。 
“ GET/chain: 返回 当前 的 区 块 链 。 


基础 代码 如 下 : 





Const express = require('express'); 
const uuidv4 = require('uuid/v4'); 
const Blockchain = require('./blockchain') .Blockchain; 


const port = process.env.PORT || 3000; 
Const app = express () 7 

Const nodeIdentifier = uuidv4(); 
const testCoin = new Blockchain (); 


// 接口 实现 
app.get('/mine', (req res) => { 
res.send("We'll mine a new block."); 


1); 


app.post('/transactions/new', (req res) => { 
res.send("We'll add a new transaction."); 


DD); 


app.get('/chain', (req, res) => { 
const response = { 
chain: testCoin.chain, 
length: testCoin.chain.length 
res.send (response); 


DD 


app.listen(port, () => { 
console.1og(`Server is up on port $fPort} ) 7 


DD); 





下 面 我 们 完善 路 由 /mine 以 及 /transactions/new， 并 添加 一 些 日 志 功能 ( 非 必需 ) 。 








先 来 看 路 由 /transactions/new， 在 这 个 接口 中 ， 我 们 接收 一 个 JSON 格 式 的 交易 ， 内 容 如 下 : 











"sender": "my address", 
"recipient": "someone else's address", 
"amount": 5 


} 














然后 ， 把 该 交易 添加 到 当前 区 块 链 的 currentTransactions 中 。 这 里 会 用 到 body-parser 模 块 ， 最 后 的 代码 为 : 

















Const bodyParser = require("body-parser"); 
const jsonParser = bodyParser.json(); 
app.post('/transactions/new', jsonParser, (req, res) => { 
const newTransaction = req.body; 
testCoin.addNewTransaction (newTransaction); 
res.send(‘The transaction ${JSON.stringify (newTransaction)} is successfully added to the blockchain。) 7 
]) 

















接 下 来 是 路 由 /mine。 该 接口 实现 的 功能 是 收集 当前 未 被 打包 的 交易 ， 将 其 打包 到 一 个 新 的 区 块 中 ; 添加 奖励 交易 (这 里 设置 为 50， 接 收 地 址 为 uuid) ;进行 符合 难度 要 求 的 挖 矿 ， 返 回 新 区 块 信息 。 
代码 实现 如 下 : 














app.get('/mine', (req, res) => { 
const latestBlockIndex = testCoin.chain.length; 
Const newBlock = new Block(latestBlockIndex, new Date () .toString ()) 7 
newBlock.transactions = testCoin.currentTransactions; 
// Get a reward for mining the new block 
newBlock.transactions.unshift({ 
sender: '0', 
recipient: nodeldentifier, 
amount: 50 
]) 
testCoin.addBlock (newBlock); 
testCoin.currentTransactions = []; 
res.send( “Mined new block ${JSON.stringify (newBlock, undefined, 2)}°); 
Ds 








至 此 ， 代 码 基 本 完成 ， 最 后 我 们 添加 一 个 记录 日 志 的 中 间 件 : 








app.use((req, res, next) => { 

Var now = new Date () .toString (); 

Var log =“$fnow}: ${req.method} S${req.ur1] 7 

Console.1og(1og) 7 

fs.appendFile('server.log', log + '\n', (err) => { 
if (err) console.error (err); 
Ed 
next (); 
1) 





4 测试 API 











使 用 Node Serverjs 启 动 应 用 ， 我 们 使 用 Postman 来 对 当前 的 API 进 行 测试 。 




















在 启动 应 用 后 ， 当 前 区 块 链 应 该 只 有 一 个 创 世 区 块 ， 我 们 使 用 /chain 来 获取 当前 区 块 链 信息 ， 如 图 1-3 所 示 。 














可 以 看 到 ， 当 前 区 块 链 只 有 一 个 区 块 。 那 怎么 添加 新 的 交易 呢 ? 方法 如 图 1-4 所 示 。 








localhost:3000/chain 


Preview JSJONv 己 


"chain": [ 
{ 
"index": 0, 
"timestamp": “91/16/2617”， 
“transactions": [ 
{ 
"sender": "Leo", 
"recipient": "Janice", 
"amount": 520 
} 
]， 
“previousHash": "0", 
“hash":; "31bl5cc32d6772f237dcf298d5b7a2417f298f48ce6d8d5fbe87958141df7a4c"， 
“nonce": 0 


} 
]， 
"length": 1 





图 1-3 ”区 块 链 信息 


POST YY localhost:3000/transactions/new 


Authorization Headers (1) Body @ Pre-request Tests 


form-data x-www-form-urlencoded 团 raw JSON (application/json) Y 


"sender": "Alice", 
"recipient": "Bob", 
“amount": 1666 





图 1-4 区 块 链 里 的 交易 


把 交易 以 JSON 的 形式 添加 到 请 求 的 gody 中 ， 返 回 结果 如 图 1-5 所 示 。 





Pretty Raw Preview HTML YY 之 


1 The transaction {"sender":"Alice","recipient":"Bob","amount":1800} is successfully added to the blockchain.| 





图 1-5 交易 的 返回 结果 








接 下 来 ， 我 们 可 以 进行 挖 矿 了 : 把 当前 的 交易 打包 到 新 的 区 块 ， 并 给 自己 分 配 奖 励 。 这 次 我 们 使 用 mine 接 口 ， 如 图 1-6 所 示 。 























GET localhost:3000/mine 


uthorization Headers 





图 1-6 ”调用 mine 接 口 


返回 的 结果 如 图 1-7 所 示 。 





Pretty 


Mined new block { 
"index": 1,， 
"timestamp": “Sat Oct 87 2817 18:35:58 GMT+8888 (DST)", 
"transactions": [ 
{ 
"sender": "0", 
"recipient": "3a738f2c-65fc-4e@f-85bb-elbdfd6ac894",， 
"amount": 50 
}， 
{ 


"sender": { 
"sender": "Alice", 
"recipient": "Bob", 
“amount": 1060 


} 


} 
]， 
"previousHash": "31b15cc32d6772f237dcf298d5b7a2417f298f40ce6d8d5fbe67958141df7a4c”， 
"hash": "9606a61778561e7669e7d68b692b97d165c336c758f3538b916bb497d16d98db6f”， 
“nonce": 1531 


| 





图 1-7 挖 出 第 一 个 区 块 





可 以 看 到 ， 交 易 已 经 被 打包 到 新 的 区 块 中 了 。 新 的 区 块 中 包含 一 笔 奖励 交易 ， 难 度 也 符合 要 求 (连续 3 个 0) 。 





至 此 ， 三 个 接口 全 部 工作 正常 ， 我 们 也 可 以 继续 添加 交易 、 挖 矿 ， 一 直 进 行 下 去 。 





有 人 会 问 : 如 果 不 添加 交易 是 否 可 以 挖 矿 呢 ? 答案 是 Yes! 一 般 在 一 个 区 块 链 项 目的 早期 ， 交 易 的 数量 可 能 一 天 也 没有 几 笔 。 但 是 挖 矿 的 工作 是 要 一 直 进行 下 去 的 ， 只 不 过 每 个 区 块 除 了 奖励 交易 再 没有 
其 他 了 ， 这 种 区 块 一 般 成 为 “ 空 块 ”。 在 我 们 这 里 也 可 以 实现 ， 不 添加 交易 ， 直 接 调 用 mine 接 口 ， 如 图 1-8 所 示 。 


















































此 时 ， 再 查看 区 块 链 信息 ， 就 可 以 看 到 刚刚 建立 的 两 个 区 块 了 ， 如 图 1-9 所 示 。 














GET Y localhost:3000/mine 


Authorization Heart 


Body Cookies 


ders 


Headers (6) 


Pretty Raw Preview 


Mined new block { 


"index": 2， 


Pre-request Script Tests 


Tests 


HIML ”之 


No Auth 


"timestamp": “Sat Oct 87 2817 18:41:37 GMT+8888 (DST)", 
"transactions": [ 


{ 


"sender": "0", 
"recipient": "3a738f2c-65fc-4e8@f-85bb-elbdfd6ac894", 
"amount": 50 


} 
]， 


"previousHash"”: "68606a81778561e7690e7d68b82b97d165c338c758f3538b916bb497d18d98db6f"， 
"hash": "88983b23d8beaaf9f7937abc123182f86a56ae69ea8f9e181344b9f6df4cae561"， 
"nonce": 3228 


1.3 ”本 章 总 结 


图 1-8 挖 出 第 二 个 区 块 





本 章 实现 了 一 个 简单 的 区 块 链 ， 这 个 








区 块 链 只 实现 了 








上 的 资料 对 本 章 所 实现 的 区 块 链 进行 后 续 功能 的 扩展 。 


参考 资料 : 


* Implementing proof-of-work 





区 块 和 





区 块 链 的 创建 、 工 作 量 证 明 算法 等 ， 其 实 ， 





https://www.savjee.be/2017/09/Implementing-proof-of-work-javascript-blockchain/ 


* Learn Blockchains by Building One 


https://hackernoon.com/learn-blockchains-by-building-one-117428612f46 


* Building Blockchain in Go 


https://jeiwan.cc/posts/building-blockchain-in-go-part-2/ 


* Bitcoin whitepaper 


https://bitcoin.org/bitcoin.pdf 


区 块 链 里 还 有 其 他 于 











要 的 部 分 并 没有 在 这 里 实现 ， 比 如 P2P 通 信 





、UTXO 等 。 大 家 可 以 自行 参考 网 


localhost:3000/chain 





Body Cookies Headers (6) Tests 


Preview JoNv 之 


[ 


"index": 9， 
"timestamp": "01/10/2817", 
"transactions": [ 


{ 


"sender": "Leo”， 
"recipient": "Janice", 
“amount": 520 


} 
]， 
"previousHash": “9”， 
“hash": “31b15cc32d6772f237dcf298d5b7a2417f298f469ce6d8d5fbe97958141df7a4c”， 


“nonce": 0 


RE 
"timestamp": “9at Oct 97 2617 18:35:58 GMT+60866 (DST)", 
"transactions": [ 


{ 


"sender": "0", 
"recipient": "3a738f2c-65fc-4e8f-85bb-elbdfd6ac894"， 
“amount": 50 


"sender": { 
"sender": "Alice", 
"recipient": “Bob”， 
“amount": 10606 


} 
]， 
“previousHash": “31b15cc32d6772f237dcf298d5b7a2417f298f46ce6d8d5fbe67958141df7a4c”， 


"hash": “090696ag91778561e796e7d68b62b97d165c339c758f3538b916bb497d16d98db6f”， 
"nonce": 1531 


"index": 2， 
"timestamp": "Sat Oct 87 2817 18:41:37 GMT+8888 (DST)", 
"transactions": [ 


{ 
“sender": "0", 
"recipient": "3a738f2c-65fc-4egf-85bb-elbdfd6ac894"”， 
“amount": 50 


} 
]， 
"previousHash": "880686a01778561e786e7d68b82b97d165c338c758f3538b916bb497d18d98db6f"， 
"hash": “9663b23d6beaaf9f7937abc123192f696a56ae69ea8f9e191344b9f6df4cae561”， 
“nonce": 3228 


} 
]， 


"length": 3 





图 1-9 区 块 链 信息 


第 2 章 ”DApp 开 发 简介 





在 开发 一 个 区 块 链 应 用 之 前 ， 我 们 首先 需要 了 解 智能 合约 和 DApp (Decentralized Application) 的 概念 。 本 章 首先 介绍 智能 合约 的 概念 以 及 智能 合约 的 案例 ， 然 后 解释 DApp 的 概念 及 特点 ， 最 后 介绍 
目前 几 个 主流 的 区 块 链 应 用 开发 平台 。 




















2.1 智能 合约 




















我 们 先 来 看 一 下 合约 的 定义 ， 根 据 维基 百科 ,合约 是 这 么 定义 的 : 合同 (或 合约 ) 是 以 双方 当事人 互相 对 立 合 致 的 意思 表示 所 构成 的 ， 其 中 包括 要 约 及 承诺 两 个 基本 的 意思 表示 。 要 约 是 表意 人 所 发 








出 ， 欲 得 到 相对 人 承诺 而 发 生 一 定 私法 上 效力 的 意思 表示 。 承 诺 则 是 针对 要 约 所 为 的 肯定 答复 ， 承 诺 的 内 容 必 须 和 该 要 约 的 内 容 完全 一 致 ， 否 则 即 为 新 要 约 而 非 承诺 。 应 与 要 约 区 分 的 是 要 约 之 引诱 ， 其 并 


非 意思 表示 ， 而 是 观念 通知 ， 为 准 法 律 行为 之 一 种 ， 不 生 要 约 拘束 力 。 

















那 什么 是 智能 合约 呢 ? 智能 合约 的 概念 由 计算 机 科学 家 尼克 :萨博 (Nick Szabo) 于 1993 年 左右 提出 。1994 年 他 把 智能 合约 的 概念 整理 为 论文 ， 这 也 是 智能 合约 首次 正式 提出 。 在 这 篇 论文 里 ， 尼 克 萨 














博 给 出 智能 合约 的 定义 如 下 : “智能 合约 超越 了 自动 售 货 机 中 嵌入 各 种 有 价 属性 的 范畴 ， 通 过 数字 方式 控制 合约 。 智 能 合约 涉及 具有 动态 性 、 频 繁 主动 执行 属性 的 财产 ， 且 提供 更 好 的 观察 和 验证 点 ， 其 中 








主动 积极 的 措施 必须 丝毫 不 差 。” 




















简单 来 说， 智能 合约 就 是 把 双方 的 约定 、 条 件 以 代码 的 形式 存储 在 计算 机 系统 上 ， 当 一 定 的 条 件 被 触发 或 者 合约 人 主动 调用 合约 内 容 时 ， 那 么 智能 合约 就 会 被 执行 。 





智能 合约 虽然 在 理论 上 很 早 就 被 提出 ， 但 是 却 一 直 停留 在 概念 上 。 智 能 合约 的 实现 需要 几 个 条 件 : 








“ 必须 有 货币 参与 。 没 有 货币 参与 的 合约 只 能 是 空谈 。 以 前 的 货币 只 能 是 法 币 ， 加 密 货 币 的 出 现 提供 了 合约 里 价值 流通 的 手段 。 
“ 资产 必须 数字 化 。 写 在 合约 的 资产 要 数字 化 。 诞 生 于 数字 世界 的 资产 〈 比 如 游戏 里 的 装备 等 ) 天 然 具 有 数字 化 的 属性 ， 物 理 世界 中 其 他 的 实物 资产 也 必须 有 数字 化 的 手段 。 


“ 资产 必须 联网 且 绝 对 信任 某 个 数据 库 。 以 前 这 个 数据 库 是 由 一 个 中 心 化 的 组 织 保管 和 维护 的 ， 智 能 合约 的 参与 方 必 须 相 信 这 个 组 织 。 区 块 链 的 出 现 使 得 去 中 心 化 数据 的 存储 成 为 可 能 。 











简单 地 说 ， 智 能 合约 它 必 须 是 智能 的 ， 自 动 化 的 ， 不 需要 人 来 执行 的 ， 合 约 的 执行 是 自动 触发 的 。 而 这 些 特点 在 区 块 链 诞 生 以 前 是 很 难 满足 的 ， 而 区 块 链 的 内 置 资产 、 去 中 心 化 存储 等 特性 为 智能 合约 





的 部 署 和 执行 提供 了 天 然 的 土壤 。 


1. 撰 写 智能 合约 的 步骤 











撰写 一 个 智能 合约 和 撰写 通常 的 合同 比较 类 似 ， 不 过 需要 用 代码 的 形式 来 实现 而 已 。 这 里 以 以 太 坊 为 例 ， 撰 写 智能 合约 的 通常 步骤 有 : 











1) 确定 好 参与 人 、 涉 及 的 条 款 和 协议 。 























2) 将 第 一 步 确定 的 细则 使 用 智能 合约 编程 语言 (以 太 坊 上 用 的 是 Solidity) 实现 ， 编 译 成 bytebode， 然 后 部 署 到 以 太 坊 上 。 


























3) 一 旦 合约 被 部 署 到 以 太 坊 ， 那 么 这 个 合约 就 获得 了 一 个 合约 地 址 。 参 与 方 可 以 根据 合约 地 址 来 调用 智能 合约 。 

















4) 智能 合约 一 旦 被 部 署 到 以 太 坊 ， 任 何人 都 无 法 再 对 合约 进行 更 改 ， 即 使 是 最 初 合约 的 发 布 者 。 





2. 智 能 合约 案 人 


我 们 以 经 典 的 “ 先 发 货 还 是 先 打 款 ”的 问题 ， 看 一 下 智能 合约 如 何 解 决 这 个 问题 。 












































假设 A 想 要 从 B 那 里 买 一 批 货 物 ，A 和 B 在 不 同 的 城市 ， 因 此 货物 需要 托运 。 双 方 都 担心 自己 受到 欺骗 ， 因 此 A 不 想 在 没有 收 到 货 之 前 付款 ， 但 是 B 不 想 在 没有 收 到 钱 之 前 就 发 货 。 为 了 保证 交易 的 顺利 进 











行 ， 他 们 引入 了 一 个 第 三 方 C 做 担保 。A 先 把 货款 打 给 C， 当 A 收 到 货 以 后 ， 就 可 以 知 会 C 把 货款 打 给 B。 这 个 流程 用 智能 合约 实现 的 话 代 码 如 下 : 











contract Escrow { 
address buyer; 
address seller; 
adqdress agent; 


function Escrow (adqress agent, address seller) { 
// 在 这 个 智能 合约 里 ， 由 购买 方 发 起 合约 
buyer = msg.sender; 
agent = agent; 
seller = seller; 
} 
function release() { 
if (msg.sender 一 agent) 
suicide (seller) ; // 转 币 给 发 货 方 
else throw; 
’ 
function cancel() { 
if (msg.sender == agent) 
suicige (buyer); // 取消 交易 ， 货 款 返 回 给 购买 方 
else throw; 





在 这 个 智能 合约 里 ， 最 后 的 交易 结果 由 C 决 定 ， 他 可 以 根据 交易 的 结果 决定 把 货款 给 发 货 方 还 是 购买 方 。 





2.2 DApp 简 介 








经 过 前 几 年 移动 互联 网 以 及 智能 手机 的 普及 ， 相 信和 几乎 所 有 人 都 知道 了 什么 是 App (Application 的 简称 ) 。 时 间 转 眼 迈 入 区 块 链 时 代 ， 一 个 新 的 名 词 DApp 开 始 进入 大 众 的 视野 。 简 单 来 说 ，DApp 是 

















Decentralized Application 的 简称 ， 发 音 为 Dee-App， 类 似 于 E-mail。DApp 和 App 最 大 的 不 同 是 : DApp 是 运行 在 去 中 心 化 的 区 块 链 中 ， 区 块 链 提供 了 计算 资源 和 存储 资源 的 支持 ， 前 端 技术 和 传统 的 
Web 开 发 保持 一 致 。 










































































首先 我 们 来 看 一 下 DApp 的 定义 。 关 于 DApp 的 具体 理解 和 定义 ， 人 们 目前 并 没有 达成 一 致 。 有 人 认为 只 有 基于 以 太 坊 智 能 合约 开发 的 应 用 才 是 DApp， 而 有 人 也 提出 类 似 于 BitTorrent 之 类 的 P2P 应 | 




















也 


可 以 称 为 DApp。 这 里 采用 目前 最 通用 的 DApp Fund CEO David Johnston 在 文章 《Decentralized Applications White Paper and Spec》 里 的 说 法 ， 对 DApp 的 定义 做 一 个 概括 。 在 这 篇 文章 里 ， 只 有 当 


























满足 以 下 所 有 条 件 时 ， 一 个 应 用 才 可 以 称 之 为 DApp: 








“ 应 用 必须 完全 开源 、 自 治 并 且 没 有 一 个 实体 控制 着 该 应 用 的 大 部 分 代 币 (Token) 。 该 应 用 必须 能 够 根据 市 场 的 反馈 及 技术 要 求 进行 升级 ,但 是 升级 必须 由 应 用 的 用 户 达成 共识 之 后 才 可 以 进行 。 
“ 应 用 的 数据 必须 加 密 后 存储 在 公开 的 区 块 链 上 。 
“ 应 用 必须 拥有 代 币 机 制 ( 可 以 使 用 已 存在 的 代 币 或 者 新 发 行 一 种 内 置 代 币 ) ,矿工 或 者 应 用 维护 节点 需要 得 到 代 币 奖励 。 


“ 应 用 代 币 的 产生 必须 依据 标准 的 加 密 算法 ， 有 价值 的 节点 可 以 根据 该 算法 获取 应 用 的 代 币 奖励 。 





根据 以 上 的 标准 ， 比 特 币 就 是 一 个 DApp， 为 什么 这 么 说 呢 ? 我 们 来 看 一 下 比特 币 是 否 符合 上 面 的 标准 : 








: 比特 币 的 代码 完全 开源 且 不 受 中 心 组 织 的 控制 。 
“ 所 有 比特 币 的 交易 等 信息 都 可 以 在 区 块 链 上 查 到 。 
“ 比特 币 的 代 币 奖励 机 制 有 预先 内 置 的 加 密 算法 决定 ， 无 法 修改 。 矿 工 由 于 维护 比特 币 节点 的 安全 和 稳定 获取 奖励 。 


“ 所 有 比特 币 区 块 链 上 数据 的 修改 都 要 经 过 大 多 数 用 户 的 认可 (共识 ) 。 











可 见 ， 比 特 币 是 一 个 DApp，Asch 是 一 个 DApp， 而 基于 Asch 开 发 的 CCTime 也 是 一 个 DApp。 不 同 的 是 ， 有 些 DApp 扮 演 了 操作 系统 的 角色 (比如 Ethereum、Asch) ， 基 于 这 些 平台 可 以 很 容易 地 
发 出 特定 需求 的 DApp， 而 有 些 DApp (比如 CCTime) 则 是 具体 的 应 用 。 









































那么 ，DApp 有 哪些 核心 要 素 呢 ? 



































你 可 以 从 零 开始 ， 自 己 创造 一 个 完整 的 区 块 链 系统 并 开发 自己 的 应 用 。 这 相当 于 开发 一 个 新 的 区 块 链 项 目 ， 比 较 费 事 费 力 且 对 个 人 能 力 要 求 较 高 。 如 果 你 只 是 一 个 普通 的 开发 者 ， 想 基于 区 块 链 开发 自 
己 的 应 用 ， 那 么 选择 一 个 成 熟 的 区 块 链 应 用 开发 平台 就 好 了 。 这 些 平台 一 般 会 提供 完善 的 接口 以 及 开发 工具 ， 你 只 需要 操心 业务 逻辑 及 其 实现 就 好 了 。 关 于 区 块 链 的 底层 部 分 ， 这 些 平台 都 会 帮 你 处 理 好 。 
无 论 用 哪 种 方法 ，DApp 的 核心 要 素 包括 如 下 几 点 : 

























































































“ 开发 平台 。 目 前 最 流行 的 开发 平台 是 Ethereum: Ethereum 是 目前 全 球 除了 比特 币 以 外 第 二 大 的 区 块 链 项 目 ， 它 就 像 一 台 遍 及 全 世界 的 分 布 式 计算 机 ， 你 只 需要 把 你 的 应 用 部 署 在 Ethereum 上 ， 应 用 的 
运行 就 可 以 由 所 有 的 Ethereum 节 点 来 保证 了 。 应 用 的 运行 需要 支付 手续 费 (GAS) 。 缺 点 是 需要 学 习 一 门 新 的 语言 Solidity。 另 外 一 个 平台 是 现在 笔者 所 在 团队 开发 的 Asch (中 文 名 叫做 阿 希 ) 。 只 要 掌握 
JavaScript， 就 可 以 基于 Asch 开 发 DApp。Asch 采 用 的 是 侧 链 架构 ， 每 一 个 DApp 就 是 一 套 侧 链 。 侧 链 可 以 有 独立 的 区 块 链 和 节点 网 络 。 不 同 的 DApp 之 间 互 相 不 会 影响 。 不 同 于 Ethereum，Asch 系 统 上 DApp 数 量 
的 增加 不 会 增加 主 链 的 负担 ， 是 一 套 更 加 先进 的 机 制 。 


“ 共识 机 制 。 共 识 机 制 决定 了 运行 DApp 的 各 节点 如 何 达 成 共识 及 获取 奖励 ， 目 前 最 常用 的 共识 机 制 有 POW、POS 以 及 DPoS 等 。 POW 依 据 计算 资源 分 配 奖 励 ， 目 前 Bitcoin、Ethereum 都 采用 了 这 种 机 制 
(不 过 Ethereum 后 面 可 能 要 迁移 到 POS) 。Asch 采 用 的 是 DPoS 机 制 ， 核 心 系统 是 由 101 个 委托 人 节点 组 成 ， 委 托 人 是 被 社区 选举 的 可 信 账 户 ， 得 票 最 高 的 101 个 委托 人 负责 生产 区 块 。 得 票 排 名 未 进入 前 101 名 
的 账户 被 称 为 候选 人 ， 当 他 们 将 来 获得 足够 多 的 选票 并 进入 前 101 名 后 ， 将 成 为 正式 的 委托 人 。 基 于 Asch 开 发 的 DApp 默 认 采 用 这 种 共识 机 制 ， 不 过 开发 者 可 以 自己 修改 并 决定 使 用 哪 种 共识 机 制 。 
: 代 币 分 发 。 一 般 DApp 都 会 内 置 代 币 (Token) ， 而 想 让 更 多 用 户 参 与 到 DApp 的 维护 与 使 用 中 的 话 ， 就 需要 考虑 好 如 何 把 代 币 分 发 到 用 户 手 中 。 目 前 最 常见 的 有 以 下 几 种 方案 。 挖 矿 : 以 Bitcoin 为 例 ， 
任何 拥有 计算 资源 的 人 都 可 以 加 入 到 Bitcoin 的 挖 矿 中 来 ， 通 过 挖 矿 奖 励 来 获取 新 的 Bitcoin。ICO: 可 以 简单 理解 为 众 筹 。 通 过 收集 市 面 上 已 经 成 熟 的 其 他 代 币 ， 根 据 一 定 比 例 兑 换 为 本 DApp 内 的 代 币 来 完 
成 。Ethereum 就 是 按照 1BTC/2000ETH 的 比例 通过 ICO 众 筹 到 了 很 多 Bitcoin 作 为 起 始 资金 。 目 前 这 种 分 发 方式 在 国内 已 被 禁止 。 空 投 : 将 代 币 免费 分 发 到 用 户 手中 。 持 有 其 他 代 币 的 用 户 只 需要 完成 一 个 简单 


的 绑 定 流程 ， 就 可 以 得 到 代 币 。 最 近 的 案例 有 CCTime 空 投 ， 具 体 方式 可 参考 CCTime 官 网 。 私 慕 : 这 与 找 投资 一 样 ， 依 个 人 能 力 而 定 。 


一 个 DApp 的 生命 周期 主要 分 为 三 部 分 : 



































1) 撰写 白皮书 。 白 皮 书 描述 了 DApp 的 技术 原理 、 要 解决 的 问题 以 及 特点 等 。 社 区 对 白皮书 的 反馈 可 以 添加 到 后 期 的 更 新 中 。 

















2) 分 发 代 币 。 可 以 采用 上 一 节 描述 的 代 币 分 发 机 制 的 一 种 。 
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3) 开发 DApp， 逐 步 进 化 完善 。 在 DApp 发 布 之 后 ， 如 果 该 DApp 走 向 了 一 个 健康 发 展 的 道路 ， 可 以 期 望 会 有 越 来 越 多 掌握 各 种 技能 的 用 户 加 入 到 社区 ， 一 起 维护 DApp 的 发 展 。 这 时 早期 开发 者 在 社 
所 占 的 比重 越 来 越 小 ，DApp 的 发 展 交 由 社区 整体 进行 运营 、 更 新 。 无 论 是 比特 币 还 是 比特 股 ， 早 期 开发 者 所 起 到 的 作用 已 经 越 来 越 小 ， 去 中 心 化 的 社区 已 经 可 以 推动 这 些 项 目的 继续 发 展 。 
















































































目前 社会 对 DApp 开 发 的 关注 刚 开始 ， 市 面 上 还 难以 看 到 流行 的 DApp 应 用 。 随 着 区 块 链 技术 的 发 展 ， 传 统 的 C/S 模 式 可 能 会 被 颠覆 ， 开 发 者 也 不 用 再 去 买 云 服务 器 部 署 自己 的 应 用 。 有 了 区 块 链 开发 平 
台 ， 开 发 者 可 以 很 容易 地 把 应 用 部 署 到 区 块 链 上 ， 这 是 一 个 基于 全 球 服务 器 ，7x24 不 间断 服务 的 应 用 平台 。 另 外 由 于 DApp 代 币 机 制 的 存在 ， 开 发 者 可 以 很 容易 地 基于 代 币 获得 价值 回报 。 相 信 在 不 久 的 将 
来 ，DApp 会 超越 传统 App， 在 人 们 的 社会 生活 中 扮演 越 来 越 重要 的 角色 。 







































































2.3 ”区 块 链 应 用 开发 平台 简介 






























































开发 区 块 链 应 用 的 最 快捷 方式 就 是 选择 一 个 合适 的 开发 平台 ， 利 用 平台 提供 的 开发 工具 和 基础 资源 ， 完 成 业务 代码 的 编写 和 部 署 。 目 前 比较 成 熟 的 区 块 链 应 用 开发 平台 有 以 太 坊 、Asch 以 及 
Hyperledger 等 。 本 章 会 介绍 这 三 个 平台 的 特点 ， 读 者 可 以 根据 自己 的 需求 自行 决定 选择 哪个 平台 来 进行 后 续 开 发 。 












































2.3.1 以 太 坊 





主 网 上 线 时 间 : 2015.7.30 


平台 开发 语言 : Go 





| 














智能 合约 开发 语言 : 主要 是 Solidity， 也 有 其 他 的 开发 语 











代码 仓库 地 址 : https://github.com/ethereum 


























以 太 坊 (Ethereum) 是 一 个 开源 的 区 块 链 智能 合约 开发 平台 。 和 比特 币 不 同 ， 以 太 坊 提供 了 一 个 支持 图 灵 完备 的 智能 合约 开发 语言 以 及 其 他 更 加 灵活 的 架构 。 开 发 者 可 以 基于 以 太 坊 提供 的 开发 语言 和 
接口 开发 区 块 链 应 用 。 以 太 坊 的 区 块头 如 图 2-1 所 示 。 















































Block header 





图 2-1 以 太 坊 的 区 块头 


2014 年 7 月 ~ 8 月 ， 以 太 坊 团队 通过 ICO 的 方式 销售 了 系统 的 内 置 代 币 ETH， 换 取 了 大 量 的 比特 币 用 于 以 后 的 研发 和 运营 。 这 也 是 全 球 第 一 个 ICO 项 目 。 当 时 1 个 ETH 的 价格 在 3 元 左右 ， 现 在 的 价格 已 经 
是 5000 多 元 。3 年 多 的 时 间 实 现 了 1600 多 倍 的 增长 ， 早 期 的 投资 人 都 获得 了 极为 丰厚 的 回报 。 








这 里 我 们 详细 对 比 一 下 以 太 坊 和 比特 币 : 





:以太 坊 是 一 个 智能 合约 开发 平台 ， 它 支持 图 灵 完备 的 开发 语言 。 通 过 这 种 语言 ， 可 以 开发 功能 非常 丰富 的 智能 合约 ， 目 前 最 流行 的 语言 是 Solidity。 这 大 大 扩展 了 平台 的 用 途 ， 而 不 仅仅 是 作为 一 个 电 
子 货币 流通 平台 。 


“ 比特 币 原理 简单 ， 但 功能 也 有 限 ， 目 前 只 能 作为 一 个 封闭 的 数字 货币 流通 平台 来 运转 ， 几 乎 没有 可 扩展 性 如 图 2-2 所 示 。 





打 个 比方 ， 这 就 像 是 有 两 条 河 ， 其 中 一 条 河 叫 比特 币 ， 你 只 能 站 在 岸 边 看 着 它 流 消 ， 什 么 也 干 不 了 。 而 另 一 条 河 叫 以 太 坊 ， 你 可 以 自己 造船 下 河 。 你 的 船 可 以 拉客 、 可 以 运 货 ， 甚 至 可 以 养 猫 ， 这 就 大 
大 提高 了 这 条 河 的 利用 率 。 这 种 模式 相 比比 特 币 来 说 是 一 个 非常 大 的 进步 ， 但 是 以 太 坊 就 没有 问题 了 吗 ? 这 就 引出 了 下 一 个 问题 一 一 以 太 坊 的 拥堵 问题 。 


以 太 坊 vs 比特 币 
以 太 坊 











智能 合约 运行 平台 区 块 链 及 加 密 货币 的 标准 制定 者 
资产 :ETH 资产 : BTC 


资产 用 于 激励 ， 不 是 最 主要 目的 BTC 是 主要 目的 
特性 丰富 机 制 简单 

图 灵 完 备 的 脚本 语言 非 图 灵 完 备 的 脚本 语言 
基于 账户 基于 UTXO 

共识 算法 : 目前 是 POW， 计 划 迁 共识 机 制 : POW 
移 到 POS 





图 2-2 ”以 太 坊 和 比特 币 的 对 比 





前 面 讲 到 了 任何 人 都 可 以 在 以 太 坊 这 条 大 河上 造船 开展 自己 的 业务 ， 但 是 河 只 有 一 条 ， 如 果 船 多 了 会 怎么 样 ”拥挤 ， 对 吧 。 这 也 是 我 们 在 过 去 几 年 经 常 能 看 到 的 现象 ， 那 就 是 以 太 坊 的 网 络 拥堵 。 最 近 
的 一 次 拥堵 发 生 在 本 书写 作 的 2018 年 ， 一 款 基 于 以 太 坊 开发 的 养 猫 游戏 流行 起 来 ， 它 一 度 占据 以 太 坊 20% 的 流量 ， 造 成 了 以 太 坊 主 链 的 拥堵 ， 影 响 到 了 基于 以 太 坊 开发 的 所 有 其 他 应 用 。 这 就 相当 于 以 太 坊 
这 条 河中 突然 出 现 了 一 条 大 船 ， 搞 得 其 他 船 都 没有 空间 了 。 

















2.3.2 Asch 


主 网 上 线 时 间 : 2016.8.16 
平台 开发 语言 : Node.JS 
智能 合约 开发 语言 : JavaScript 


代码 仓库 地 址 : https://github.com/AschPlatform 

















Asch 是 一 个 去 中 心 化 的 应 用 平台 ， 其 架构 如 图 2-3 所 示 。 它 提供 了 一 系列 的 SDK 和 API 来 帮助 开发 者 构建 基于 JavaScript 和 侧 链 技术 的 去 中 心 化 应 用 。Asch 通 过 提供 定制 侧 链 、 智 能 合约 、 应 用 托管 等 一 
体 化 的 行业 解决 方案 ， 致 力 于 打造 一 个 易于 使 用 、 功 能 完备 、 即 插 即 用 的 系统 。 利 用 Asch 生 态 系统 ， 开 发 者 可 以 快速 迭代 自己 的 JavaScript 应 用 ， 并 发 布 到 系统 内 置 的 应 用 商店 中 ， 这 些 应 用 可 以 被 平台 中 
的 分 布 式 节点 下 载 并 执行 ， 并 服务 于 普通 用 户 ， 整 个 过 程 都 由 Asch 侧 链 共识 网 络 提供 安全 保证 。 





图 2-3 Asch 的 架构 











Asch 系 统 本 身 也 是 一 个 完全 开放 的 、 去 中 心 化 的 应 用 ， 内 置 有 代 币 ， 单 位 为 XAS， 中 文 名 叫 Asch 币 。Asch 币 可 以 通过 双向 锚 定 的 方式 与 侧 链 或 DApp 进 行 交 互 ， 作 为 所 有 DApp 之 间 资 产 转换 的 桥梁 和 
媒介 ， 这 些 代 币 将 在 系统 发 布 之 前 以 众 筹 的 方式 预 售 给 投资 人 。 系 统一 旦 发 布 ，Asch 最 初 的 核心 团队 将 不 再 掌控 系统 的 走向 ， 只 有 系统 的 权益 人 和 代 币 的 拥有 者 决定 系统 将 来 的 发 展 。 











Asch 平 台 除 提供 一 些 基 本 服务 外 ， 还 将 提供 技术 和 工具 上 的 支持 ， 主 要 面向 以 下 群体 : 


“ 开发 者 。 开 发 者 可 以 根据 Asch 平 台 的 应 用 开发 规则 和 商业 行为 准则 ， 并 按照 相关 的 规范 进行 开发 和 提交 DApp。DApp 的 商业 模式 或 免费 ， 或 定价 销售 ， 或 按 增 值 服 务 付费 。 采 用 何 种 商业 模式 完全 由 
开发 者 决定 。 


“ 企业 。Asch 平 台 提 供 的 工具 可 以 非常 容易 地 创建 一 个 完整 的 区 块 链 ， 更 重要 的 是 可 以 模 入 到 Asch 平 台 的 主 链 或 者 比特 币 的 区 块 链 中 ， 实 现 与 成 熟 电 子 货 币 的 对 接 ， 这 对 中 小 型 企业 ， 特 别 是 初创 企业 
是 非常 有 吸引 力 的。 中 小 企业 可 以 通过 区 块 链 技 术 提供 原本 封闭 在 企业 内 部 、 互 联网 内 部 的 信息 和 数据 ， 甚 至 与 监管 机 构 的 相关 系统 数据 相互 链接 ， 增 强 透明 度 ， 以 此 树立 良好 的 形象 ， 赢 得 投资 者 、 人 金融 
机 构 的 信任 度 ， 顺 利 拿 到 融资 或 项 目 合同 等 。 中 小 企业 主动 公开 和 开放 资料 ， 已 成 无 法 阻挡 的 趋势 。 因 为 现在 有 很 多 的 公开 渠道 来 获取 数据 ， 中 小 企业 已 经 越 来 越 难 隐 瞒 它们 不 想 让 外 界 知 道 的 信息 。 我 们 
可 以 大 胆 预测 ， 区 块 链 将 是 未 来 帮助 中 小 企业 发 展 的 重要 武器 。 





“ 普通 用 户 。 普 通用 户 可 以 通过 Asch 内 置 的 应 用 商店 进行 下 载 、 安 装 和 使 用 去 中 心 化 应 用 ， 这 跟 手 机 平台 的 应 用 商店 是 类 似 的 模式 。Asch 系 统 支持 多 种 类 型 的 去 中 心 化 应 用 ， 普 通用 户 在 消费 这 些 应 用 
的 同时 ， 还 可 以 通过 贡献 内 容 来 获得 收益 。 开 发 者 与 普通 用 户 将 共同 组 成 一 个 繁荣 的 生态 系统 。 


Asch 主 网 于 2016 年 8 月 16 日 上 线 ， 目 前 已 经 安全 运行 了 2 年 多 的 时 间 。 期 间 遭 遇 过 多 次 攻击 ， 但 没有 发 生 过 分 叉 或 者 宕 机 的 情况 ， 在 安全 性 和 效率 上 都 已 经 得 到 了 验证 。 


2.3.3 Hyperledger 


主 网 上 线 时 间 : 2017.7.11 


平台 开发 语言 : Go 


代码 仓库 地 址 : https://github.com/hyperledger 











Hyperledger (超级 账本 ) 是 由 Linux 基 金 会 支持 ,很 多 巨头 (包括 IBM、iIntel 等 ) 参与 一 个 面向 企业 打造 的 一 个 透明 、 公 开 的 去 中 心 化 分 布 式 账本 项 目 。 目 标 是 制定 一 个 区 块 链 技术 的 开源 规范 和 标 
准 ， 让 更 多 的 应 用 可 以 容易 地 建立 在 区 块 链 技术 之 上 。 
























































Hyperledger 目 前 包括 5 个 技术 框架 ，3+1 个 工具 包 (1 个 尚未 发 布 ) 。 这 5 个 技术 框架 分 别 是 : 

















* Sawtooth: 为 物 联 网 、 生 产 、 人 金融 以 及 企业 提供 的 区 块 链 框架 。 





“Iroha: 聚焦 于 提供 移动 库 ， 提 供 更 多 的 库 作 为 组 件 被 其 他 组 件 共同 使 用 。 


“ Fabric: 是 一 个 许可 网 络 ， 只 有 获得 许可 的 参与 者 才 可 以 接 入 网 络 。 


“ Burrow: 提供 了 一 个 模块 化 的 带 有 许可 智能 协议 解释 器 的 区 块 链 客户 端 。 


* Indy: 一 个 用 于 去 中 心 化 身份 的 分 布 式 账 本 。 





3 个 工具 包 分 别 是 : 

* Hyperledger Cello 

* Hypetledger Composer 

* Hypetledger Explorer 

: 还 有 一 个 尚未 发 布 的 工具 包 : Hyperledger Quilt 


如 果 想 要 了 解 更 详细 的 信息 ， 可 以 查看 Hyperledger 的 官网 。 


2.4 本章 总 结 












































本 章 介绍 了 智能 合约 和 DApp 的 概念 以 及 区 块 链 应 用 开发 平台 。 区 块 链 技 术 的 应 用 落地 还 刚刚 开始 ， 无 论 是 开发 智能 合约 还 是 DApp， 目 前 都 还 处 于 初始 阶段 ， 读 者 可 以 根据 自己 的 应 用 场景 选择 合适 的 
平台 进行 开发 。 


















































参考 资料 : 
* Whatis Ethereum? : 
https://coincenter.org/entry/what-is-ethereum 
“ 以 太 坊 白皮书 : 
https:/Vgithub.comyethereum/wiki/wiki/9%5B9%E496B896AD96E696969687965D-9%6E496BB96A596E596A496AA9%6E5969D968A%E7969996BD9%6E7969A96AE96E496B99%6A6 
: Hyperledger_Arch_WG_Paper_2_SmartContracts: 
https://www.hyperledger.org/wp-content/uploads/2018/04/Hyperledger Arch WG Paper 2 SmartContracts.pdf 
* Decentralized Applications White Paper and Spec: 
https://github.com/DavidJohnstonCEO/DecentralizeDApplications 
.What are DApps (Decentralized Applications) ? : 
https://coinsutra.com/DApps-decentralized-applications/ 
* Nick Szabo--The Idea of Smatrt Contracts: 


https://perma.cc/V6AZ-7V8W 
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Asch 是 一 个 基于 区 块 链 跨 链 技术 的 应 


研究 一 门 新 技术 ， 一 般 来 说 可 以 研究 该 技术 的 早期 代码 。 
前 来 说 ，Asch 是 一 个 非常 好 的 学 习 区 块 链 的 开源 项 目 。 


在 本 书 的 第 二 部 分 ， 我 们 将 会 深入 探索 Asch 的 代码 结构 及 其 功能 实 






































本 部 分 源码 解读 基于 Asch v1.4.0 (https://github.com/AschPlatform) 


第 3 章 ”Asch 一 一 区 块 链 应 用 开发 平台 


3: 

















Asch 是 一 个 在 2016 











就 发 布 主 网 
开发 经 验 ， 就 可 以 基于 Asch 快 速 构建 





的 区 块 链 应 
区 块 链 应 


















































开发 平台 。 目 的 在 于 降低 区 块 链 技术 应 和 
。 本 章 将 会 从 Asch 的 诞生 讲 起 ， 包 括 Asch 



































的 架构 、 开 发 工 


现 ， 以 帮助 大 家 理解 Asch 的 实现 逻辑 和 运转 机 制 。 


的 门槛 ， 帮 助 企 业 和 开发 者 能 够 快速 地 构建 区 块 链 应 F 




















开发 平台 ， 名 字 是 Application Side Chain 的 缩写 ， 目 前 全 部 核心 代码 已 经 在 GitHub 上 开源 。 



































(DApp) 。 开 发 者 只 要 会 使 











、 基 本 使 用 等 。 

































































希望 读者 在 读 完 本 章 后 可 以 对 Asch 有 一 个 清晰 的 了 解 。 





因为 非常 成 熟 有 名 的 代码 往往 已 经 过 度 设 计 ， 对 于 阅读 代码 入 门 不 一 定 是 好 的 选择 。 而 一 些 项 目 早期 的 代码 更 容易 阅读 并 理解 其 核心 原理 。 目 


JavaScript 以 及 有 一 定 的 
























































































































































1 Asch 的 诞生 和 架构 
Asch 于 2016 年 1 月 初 开始 开发 ， 再 经 历 对 共识 算法 的 升级 、 多 节点 及 安全 性 的 各 种 测试 以 后 ， 于 2016 年 8 月 16 日 正式 发 布 主 网 。Asch 最 初 主要 由 单 青峰 个 人 进行 开发 ， 目 前 已 经 组 建 了 完整 的 团队 进行 
后 续 的 开发 与 维护 。Asch 到 现在 已 经 正常 运行 了 两 年 多 的 时 间 ， 未 发 生 过 严重 的 安全 事故 。 已 经 发 布 的 DApPp 有 孔明 屋 、 虚 拟 地 球 等 ， 还 有 大 量 行业 应 用 正在 开发 中 。 
关于 Asch ( 阿 希 ) 名 字 的 由 来 ，Asch 的 创始 人 单 青峰 曾 做 过 解释 : A 字 代表 Application，S 代 表 Side，CH 代 表 CHain， 组 合 起 来 就 是 应 用 侧 链 的 意思 ， 见 : “Asch 名 字 的 由 来 ” ( 链 
接 : https://bbs.asch.io/topic/1614/%E9%98%BF%E5%B8%8C%E5%90%8D%E5%AD%97%E7%9A%84%E7%94%B1%E6%9D%A5) 。 
做 Asch 的 初衷 ， 单 青峰 也 在 这 篇 文章 中 进行 了 阐述 : “有 了 lisk， 为 什么 我 们 还 要 做 一 个 Asch” (链接 : http://blog.asch.so/2016/05/21/asch-why/) 。 
Asch 是 一 个 基于 侧 链 架构 的 公有 链 平台 ， 内 置 通 证 为 XAS (中 文 名 为 阿 希 币 ) 。Asch 包 括 一 套 公 有 链 系 统 以 及 一 系列 基于 该 公有 链 的 开发 工具 。Asch 以 及 基于 Asch 开 发 的 DApp 使 用 javaScript 作 为 开 
发 语言 ， 支 持 关系 数据 库存 储 数 据 ， 极 大 地 降低 了 区 块 链 开发 的 门槛 。 开 发 者 可 以 利用 Asch 提 供 的 低层 API 进 行 自由 组 合 ， 应 用 到 不 同 的 场景 ， 如 人 金融、 文件 存储 、 版 权证 明 等 。 
Asch 提 供 了 一 个 多 链 架构 的 系统 生态 ， 如 图 3-1 所 示 。 每 一 个 DApp 都 有 一 条 自己 的 应 用 主 链 并 且 对 自己 的 主 链 拥 有 极 大 的 控制 权 ， 比 如 自 定 义 手 续费 、 发 行 资产 等 。DApp 的 应 用 主 链 拥 有 自己 独立 的 
户 体系 、 数 据 库 等 。 同 时 Asch 提 供 了 可 揪 拔 的 共识 机 制 ， 不 同 的 应 用 主 链 可 以 根据 自己 的 需求 采用 不 同 的 共识 算法 。 
























































阿 希 链 ASCH 





Asch 主 链 以 及 DApp 的 核心 逻辑 使 
及 JSON RPC 等 协议 进行 通信 。 由 于 每 个 DApp 运 行 在 


基于 这 种 多 链 架构 ， 开 发 者 在 拥有 很 大 的 








Asch 还 通过 
























































Node.js 进 行 开 发 (可 外 


图 3-1 


会 逐步 迁移 到 TypeScript) 。DApp 链 提供 























己 独立 的 应 | 























主 研发 的 跨 链 协 议 来 实现 和 其 他 公有 链 之 间 的 资产 交换 。 
有 链 的 资产 可 以 接 入 到 Asch 上 来 使 





























阿 希 链 的 多 链 架构 





主 链 上 ，DApp 之 间 并 不 会 相互 影响 。 











自主 性 的 同时 有 可 以 享受 到 Asch 生 态 的 支持 ， 包 括 开发 工 


























， 而 所 有 基于 Asch 开 发 的 DApp 也 可 以 导入 其 他 公有 链 的 优质 资产 到 

















前 已 经 发 布 了 和 比特 币 的 跨 链 资 





以 及 用 户 系统 等 。 























后 端的 业务 逻辑 以 及 接口 ， 











面 则 可 以 





前 端 方 











产 交换 ， 下 一 步 将 会 完成 对 接 以 太 坊 及 ERC20 等 资产 的 跨 链 交 换 。 基 于 








己 的 应 上 








中 使 用 。 


























关 了 





跨 链 技术 的 细节 ， 详 请 参考 本 书 的 第 9 章 。 


彤 胀 以 及 拥堵 问题 。 另 外 ，Asch 主 链 上 的 资产 可 以 在 DApp 和 
































利用 Asch 的 这 种 多 链 + 跨 链 的 架构 ， 基 于 Asch 开 发 的 DApp 可 以 更 加 灵活 ， 并 且 解 决 了 单 链 架构 (比如 以 太 坊 ) 的 数据 
跨 链 协议 自由 流通 ， 实 现 “ 一 币 多 链 ， 一 链 多 币 ”，DApp 内 部 可 以 导入 其 他 主 链 上 的 各 种 资产 使 用 。 
成 为 受托 人 的 节点 有 生产 区 块 并 获取 奖励 的 权利 。 奖 励 包括 区 块 的 固定 奖励 及 转账 的 手续 费 。Asch 系 统 的 区 块 奖励 从 464500 块 开始 ， 初 始 奖励 3.5 XAS。 每 当 系统 新 增 300 万 个 
间 ) ， 区 块 的 固定 奖励 则 进行 递减 。 从 15464500 块 以 后 ， 奖 励 不 再 递减 ， 每 年 有 略 小 于 1.5% 的 通胀 率 。 区 块 固定 奖励 和 区 块 高 度 的 关系 如 表 3-1 所 示 。 
表 3-1 区 块 奖励 表 





任意 流行 的 前 端 技术 。 前 后 端 之 间 可 以 通过 HTTP 以 


连 协议 ， 其 他 公 














他 主 链 之 间 通 过 








区 块 (大 概 一 年 的 时 


区 


目前 (2018 年 11 月 ) ， 每 个 区 块 的 固定 奖励 为 2 个 XAS。Asch 系 统 每 天 产 块 总 收益 : 2*24*60*60/10=17280 XAS， 每 个 受托 人 每 天 产 块 收益 : 17280/101=171.08 XAS 




















每 个 受托 人 的 产 块 收益 中 ， 产 块 的 收益 会 自动 转 入 到 社区 基金 账户 ， 用 于 团队 的 开发 和 运营 工作 。 在 后 面 的 版 本 里 ，Asch 会 继续 改进 链 上 社区 治理 的 机 制 ， 包 括 引 入 Worker 任 务 系统 等 。 




















3.2 ”开发 工具 























目前 ，Asch 平 台 上 的 开发 工具 包括 : asch-js、asch-cli、SDK、API 等 。 








asch-js 是 一 个 辅助 开发 者 在 基于 Asch 开 发 相关 功能 的 JavaScript 库 。 利 用 asch-js 库 ， 开 发 者 可 以 在 程序 中 完成 大 多 数 Asch 主 链 支持 的 功能 ， 比 如 转账 、 发 行 资产 、 注 册 受 托 人 以 及 一 系列 的 DApp 相 关 
功能 。 详 细 文 档 请 参考 asch/asch_js_api.md。 
































asch-cli 是 一 个 运行 于 命令 行 下 的 工具 ， 主 要 用 于 通过 命令 行 的 方式 和 区 块 链 进行 交互 。asch-cli 提 供 了 一 个 DApp 的 模板 ， 帮 助 开发 者 能 够 快速 注册 一 个 DApp。 可 以 使 用 命令 asch-cli-h 查 看 帮助 文 
档 ， 详 细 文 档 请 参考 asch/asch_cli_usage.md。 
































Asch SDK 主 要 用 于 侧 链 DApp 的 开发 。 基 于 Asch 提 供 的 SDK， 开 发 者 可 以 完成 诸如 数据 模型 的 创建 、 路 由 的 配置 以 及 数据 库 读 写 等 操作 。 详 细 文 档 请 参考 asch/asch_sdk_api.md。 











运行 Asch 节 点 的 服务 器 支持 一 系列 的 HTTP 的 AP1。 通 过 系统 提供 的 AP1， 开 发 者 只 需要 按照 接口 规则 提供 数据 ， 通 过 POST/GET 的 方式 提交 给 节点 ， 节 点 则 会 返回 相应 的 结果 。 详 细 文档 请 参考 


asch/asch_http_interface.md。 





3.3 ”客户 端的 基本 使 用 
































Asch 的 客户 端 分 为 在 线 钱包 、 手 机 钱包 以 及 轻 客户 端 等 ， 用 户 可 以 根据 需求 选择 合适 的 钱包 。 下 面 以 在 线 钱包 为 例 ， 讲 解 Asch 钱 包 的 基本 使 用 。 





























1) 登录 网 址 : https://wallet.asch.io 或 者 https://mainnet.asch.io， 会 显示 登录 界面 ， 如 图 3-2 所 示 。 





[ 





《》 Asch.io 风 希 





图 3-2 客户 端 首 页 














2) 点 击 “ 新 账户 ”， 会 生成 主 密码 ， 如 图 3-3 所 示 。 


创建 钱包 


primary mountain poverty hat wolf leg 


afry Iynics hire stage Sorry 


人 Asch.io 朵 希 








图 3-3 ”生成 新 账户 








Asch 的 主 密码 遵循 BIP39 协 议 ， 由 12 个 随机 生成 的 英文 单词 组 成 。 这 个 主 密码 一 定 要 妥善 保管 ， 丢 失 之 后 无 法 找 回 。 复 制 主 密码 ， 然 后 勾 选 下 面 的 三 个 选项 ， 就 可 以 创建 钱包 了 。 














3) 点 击 下 一 步 ， 将 刚刚 生成 的 密码 输入 ， 登 录 到 系统 ， 如 图 3-4 所 示 。 





人 Asch.io 朵 希 





图 3-4 登录 到 客户 端 


4) 登录 后 的 界面 入 如 图 3-5 所 示 。 











在 首页 ， 用 户 可 以 看 到 自己 当前 的 XAS 余 额 、 昵 称 、 区 块 高 度 以 及 版 本 信息 等 ， 首 页 默认 显示 转账 记录 。 左 边栏 则 是 各 种 功能 模块 。 下 面 分 别 介绍 。 




















“资产 ”页 面 如 图 3-6 所 示 。 





最 后 区 块 高 度 ,nlnlt 789526 最 后 区 块 时 间 2018/11/14 15:48:20 


NM 你 好 EEEEB 


芒 钱包 余额 主 资 产 缀 区 转账 记录 


0 xa 


查看 全 部 资产 





图 3-5 首页 
最 后 区 块 高 度 ,ll 688119 最 后 区 块 时 间 2018/11/02 16:26:10 
。、 链 内 资产 
XAS 


89584856.9 


获取 更 多 资产 





图 3-6 ”资产 展示 





Asch 的 资产 包括 XAS， 基 于 Asch 发 行 的 链 内 资产 以 及 通过 跨 链 技术 导入 来 的 跨 链 资产 。 





“转账 ”页 面 如 图 3-7 所 示 。 





转账 是 链 上 最 频繁 的 操作 。 注 意 转账 无 法 撤消 ， 这 里 可 以 填写 备注 。 





“提案 ”页 面 如 图 3-8 所 示 。 





























提案 是 在 1.4 版 本 以 后 新 增加 的 功能 。 主 要 用 于 网 关 的 创建 于 初始 化 。 一 项 提案 在 发 起 以 后 ， 需 要 收集 到 68 以 上 的 受托 人 签名 才 可 以 生效 。 




















“网 关 ” 页 面 如 图 3-9 所 示 。 





乞 转账 * 请 确保 您 发 送 到 正确 的 地 址 ， 本 操作 无 法 撤消 


请 输入 对 方 钱包 地 址 或 昵称 





XAS 


+ 可 用 余额 : 89584856.9 











图 3-7 转账 操作 


全 部 提案 ”进行 中 的 提案 ”已 激活 的 提案 ”已 过 期 的 提案 发 起 新 提案 


提案 编号 类 型 公投 周期 提案 描述 


7c4758d 新 增 网 关 2018/08/28 18:28:28 - 2018/12/06 11:36:08 This is a proposal a... 


c09ed6a 网 关 初 始 化 2018/08/28 18:34:01 - 2018/12/06 11:36:11 This is a proposal a... 





图 3-8 ”提案 详情 


分 ”网 关 详 情 页 


成 员 ( 共 3 人 ) 


成 员 描述 


Validator description of bitcoincash gateway A28yFDa4vYU 
Validator description of bitcoincash gateway AMAwe1qp6q 


Validator description of bitcoincash gateway ABcur7keRpc: 


图 3-9 ”网 关 详情 





网 关 是 跨 链 实 现 里 的 重要 角色 。 具 体 的 实现 可 以 参考 本 书 的 第 9 章 。 








“理事 会 ”页 面 如 图 3-10 所 示 。 


成 员 ( 共 0 人 ) 


权重 比例 (总 ) 


臣 转账 记录 


A8JrM...aEjc3 1fad389e 


2018/10/09 18:16:43 


A8JrM...aEjc3 fce7b43d 
2018/10/09 18:16:31 


bitcoincash 


bitcoincash 
gateway 
description 





余额 详情 


2419776.79 xns 


+0.01 BCH 


+1000 koumei.KMC 





图 3-10 ”理事 会 





理事 会 也 是 1.4 版 本 以 后 新 添加 的 功能 。 在 1.4 版 本 以 后 ， 受 托 人 产 块 的 收益 都 会 转 到 理事 会 账户 。 


“投票 ”页 面 如 图 3-11 所 示 。 








受托 人 列表 一 © 
投票 记录 谁 投了 我 


LE 


asch_g85 AP2X73zPFKycjMTzcpSWfhJn1DAN3 


口 


asch_g78 ABfgTgyiBngsgDRnfkVFjQHZsvXQoh 


全 没有 可 用 数据 


asch_g27 ALQebR6HtF1Jf47xxFSiGf9vbD4gRz 
carolynf AFJpk9tYUVUqmrQauGX5YfWox3Vy71 票 权 代理 A 
asch_g49 A297hfQoHdGKsLzRxsvknkoX3z6yBh 
asch_g77 AGKP4ntSEA2y4VRMNdWR97Nuuxpt 


asch_g59 ADcPTKHLnDfxBjWyxVVMquPQDijfB 





DGD|0|D 


asch_g36 AK1PqWdRLCqwRuEjoaSU6wnawoiK 





图 3-11 投票 页 面 


这 里 是 Asch 共 识 的 集中 体现 。 普 通 的 持 币 人 可 以 在 对 受托 人 进行 投票 和 撤 票 。 另 外 票 权 也 可 以 托管 给 代理 人 来 投票 。 








“个 人 中 心 ” 如 图 3-12 所 示 。 





A4kkraSz7XkaVHfnEMx7YjKmThotXtoi8D ” 吕 


立刻 设置 


@ 代理 人 身份 : 注册 成 为 代理 人 


2 网 关 候选 人 : 如 何 成 为 网 关 候 选 人 ? 





图 3-12 ”个 人 中 心 页 面 





在 个 人 中 心 ， 可 以 查看 账户 的 基本 信息 ， 并 且 完 成 一 些 基本 操作 ， 比 如 设置 二 级 密码 、 锁 仓 等 。 


3.4 如何 基于 Asch 注 册 自 己 的 资产 





很 多 DApp 的 开发 者 想 要 在 应 用 里 使 用 自己 新 建 的 资产 ， 那 这 个 时 候 就 需要 在 Asch 上 注册 自己 的 资产 了 。 注 册 自 己 的 资产 步骤 如 下 : 














1) 注册 发 行商 。 点 击 客户 端 首页 的 “资产 发 行 ” 可 以 看 到 如 图 3-13 所 示 的 页 面 。 


全 资产 发 行 


我 发 行 的 资产 发 行商 
操作 资产 名 称 最 大 发 行 量 精度 当前 存量 日 其 您 还 不 是 发 行商 


注册 发 行商 
全 没有 可 用 数据 


图 3-13 ”资产 发 行 页 面 
Asch 的 资产 格式 为 “发 行商 .资产 名 称 ”， 一 个 账户 只 可 以 注册 一 个 发 行商 ， 但 是 一 个 发 行商 可 以 发 行 多 种 资产 。 注 册 发 行商 需要 花费 500 XAS， 而 注册 资产 需要 花费 100 XAS。 


点 击 “ 注 册 发 行商 ”以 后 会 弹出 一 个 用 户 协议 ， 点 击 “ 确 认 ” 以 后 出 现 “ 注 册 发 行商 ”页 面 ， 如 图 3-14 所 示 ， 可 以 填写 发 行商 名 称 以 及 描述 文字 。 


注册 友 行 两 


Basic information used for 
demonstration 


44/ 500 





图 3-14 ”注册 发 行商 


2) 注册 资产 。 发 行商 注册 完 以 后 就 可 以 进行 注册 资产 的 操作 了 。 在 图 3-13 中 点 击 “ 注 册 资产 ”， 在 确认 以 后 就 会 出 现 “ 注 册 资产 ”界面 ， 如 图 3-15 所 示 。 








填写 完 信息 后 点 击 “ 提 交 ” 上 





笔者 在 测试 网 注册 的 资产 如 图 


可 完成 资产 的 发 行 。 


3-16 所 示 。 


我 发 行 的 资产 


操作 


资产 名 称 


koumei.KMC 


这 里 的 koumei 是 发 行商 ，KMC 是 资产 名 称 。 


3.5 ”DApp 案 例 简 介 








精度 必须 为 0-16 的 整数 





图 3-15 ”注册 资产 
最 大 发 行 量 精度 当前 存量 
10000000000000 1 100000000000 


图 3-16 ”注册 成 功 后 的 资产 


Asch 是 一 个 DApp 开 发 平台 ， 目 前 (2018 年 3 月 ) 在 主 链 上 已 经 发 布 了 数 款 DApp， 覆 盖 行 业 各 有 不 同 ， 下 面 介绍 几 个 比较 成 熟 的 DApp。 


1.CCTime 


日 期 
2018/08/21 15:55:27 


1-1 of 1 < > 


CCTime 是 基于 Asch (Asch) 侧 链 技术 开发 的 分 布 式 社会 新 闻 分 享 与 交流 平台 。CCTime 在 Hacker News 的 基础 上 进行 重 构 ， 使 用 区 块 链 技术 改变 现 有 中 心 化 的 内 容 市 场 格局 ， 解 决 优质 内 容 难 以 识 
别 、 传 播 和 变现 的 问题 ， 通 过 全 新 的 内 容 价值 评估 体系 保证 优质 内 容 的 生产 者 直接 获得 收益 。 通 过 “ 打 赏 模式 ”给 予 优质 新 闻 发 布 者 、 分 享 者 代 币 激 励 ， 构 建 一 个 有 价值 且 符 合 大 众 需求 的 新 闻 聚 合 和 内 容 


分 享 平 台 。 官 网 : www.cctime.org 


2. 孔 明 


电 








机 








孔明 屋 致 力 于 打造 一 个 公正 、 安 全 、 高 效 的 社会 化 预测 市 场 平台 。 用 区 块 链 的 力量 连接 每 个 人 的 智慧 ， 通 过 汇聚 每 个 参与 者 的 知识 和 经 验 ， 实 现 对 事件 进行 精准 的 预测 。 区 块 链 公 开 透 明 、 不 可 自 改 等 
特性 让 预测 过 程 公开 公正 、 安 全 可 靠 。 通 过 经 济 激 励 机 制 促使 参与 者 真实 地 表达 自己 对 未 来 事件 的 判断 ， 大 大 降低 了 人 为 预测 的 随意 性 ， 实 现 低 成 本 高 效 的 预测 。 官 网 : www.koumei.io 
































3. 虚 拟 地 球 








虚拟 地 球 是 一 个 在 Asch 公 链 上 运行 的 VR/AR 虚 拟 现 实 与 真实 地 理 结合 的 虚拟 社区 。 以 现实 的 地 理 环境 和 城市 原型 为 基础 ， 在 现实 地 图 地 形 地 貌 的 基础 上 ， 自 由 构建 虚拟 的 、 去 中 心 化 的 人 文 空间 。 用 户 
可 以 投资 领地 或 者 自由 创建 、 体 验 ， 并 依靠 领地 、 创 造 和 体验 来 获得 代 币 收入 。 官 网 : www.dreammaking.net 


























3.6 本章 总 结 


















































Asch (ASCH) 具有 安全 可 靠 、 高 效 运行 、 系 统 灵 活 、 低 成 本 、 易 复 用 等 特征 。 使 用 JavaScript 作 为 应 用 编程 语言 ， 支 持 关系 数据 库 来 存储 交易 数据 ， 使 得 开发 一 个 Dapp 应 用 与 传统 的 Web 应 用 非常 相 
似 。 相 信 这 对 开发 者 和 中 小 型 企业 有 很 大 的 吸引 力 ， 只 有 开发 者 的 生产 力 提 高 了 ， 整 个 平台 的 生态 才能 够 更 迅速 繁荣 起 来 。 






















































































Asch 在 设计 上 也 是 开放 的 ， 并 没有 局 限于 某 个 细 分 领域 ， 可 以 自由 组 合 其 功能 实现 各 种 不 同 的 应 用 。 在 新 闻 聚 合 、 发 行 资产 、 仲 裁 、 存 在 性 证 明 、 产 权 认证 、 物 联网 、 供 应 链 金融 、 资 产 数字 化 、 商 品 
溯源 、 预 付 卡 系统 、 区 块 链 合同 存 证 等 方面 都 有 极 大 发 挥 空间 。 
































在 共识 机 制 方面 ，Asch 继 承 并 增强 了 DPoS 算 法 ， 大 大 降低 了 分 叉 几 率 和 双重 支付 风险 。 另 外 ，Asch 的 侧 链 不 但 延缓 了 区 块 链 膨胀 问题 ， 还 使 得 DApp 更 加 灵活 和 个 性 化 。 












































Asch 是 一 个 具有 前 瞻 性 的 、 低 成 本 的 一 站 式 DApp 解 决 方案 和 新 一 代 去 中 心 化 应 用 的 及 化 器 。 秉 承 着 成 就 企业 、 引 领 创新 、 信 仰 技术 、 拥 抱 未 来 的 价值 观 ，Asch 致 力 于 打造 一 个 全 球 商用 区 块 链 应 用 生 
态 圈 ， 不 仅 是 用 区 块 链 技术 赋 能 各 行业 ， 更 希望 成 为 能 承载 世界 级 经 济 体 的 底层 基础 。 
























































参考 资料 : 

" Asch 论 坛 : 
https://bbs.asch.io/ 
. Asch 代 码 仓库 : 


https://github.com/AschPlatform/ 





* Asch 官 网 : 


https://www.asch.io/ 


第 4 章 ”Asch 源 码 概览 











对 于 区 块 链 项 目 来 说， 核心 代码 开源 是 基本 的 要 求 ， 这 种 情况 也 为 我 们 提供 了 大 量 的 学 习 资源 。 阅 读 项 目 源码 是 深入 了 解 一 个 项 目的 最 好 方式 。 从 本 章 开 始 ， 我 们 将 会 一 起 从 源码 开始 探索 Asch 的 实现 
与 运行 机 制 。 本 章 先 介绍 Asch 生 态 架 构 ， 然 后 介绍 相关 源码 库 ， 并 介绍 了 Asch 主 链 的 启动 流程 。 


4.1 Asch 生 态 架构 
































Asch 自 2016 年 8 月 份 上 线 以 来 ， 到 现在 已 经 发 展 出 了 比较 完善 的 生态 体系 ， 包 括 底层 公 链 层 、 扩 展 层 、 应 用 层 ， 整 体 架构 如 图 4-1 所 示 。 





























Asch 的 相关 源码 库 包括 : 





*“ asch 


Asch 源 码 ， 定 义 了 Asch 里 数据 结构 、 合 约 类 型 以 及 接口 ， 底 层 由 asch-core 提 供 服 务 。 





"asch-cote 


Asch 核 心 模块 ， 定 义 了 区 块 链 的 基本 逻辑 ， 包 括 加 密 算法 、 交 易 的 生成 及 验证 、 区 块 的 生成 及 验证 和 P2P 通 信 等 。 


* asch-smartdb 





Asch 独 立 研 发 的 ORM 模 块 ， 支 持 关系 型 数据 库 以 及 Key-Value 型 的 数据 库 。 


“ asch-sandbox 一 一 侧 链 核心 模块 ， 提 供 了 侧 链 的 低层 支持 以 及 虚拟 机 。 





跨 链 模 块 ， 对 Asch 提 供 跨 链 资产 的 转 入 与 转 出 。 


* asch-gateway- 





命令 行 工 具 ， 主 要 用 于 在 命令 行 下 和 Asch 主 链 进行 交互 。 


* asch-cli 





* asch-js 


客户 端 模块 ， 可 以 用 于 在 前 端 或 者 Node.js 里 和 Asch 主 链 进 行 交互 。 





* asch-frontend: 


网 页 客户 端 ，http://mainnet.asch.io 由 该 库 提 供 支 持 。 








“ asch-smartcontract 


智能 合约 模块 ， 用 于 Asch 主 链 的 智能 合约 功能 。 


应 用 层 


扩展 层 


网 络 层 : asch-core 


公 链 层 


存储 层 : asch-smartdb 





图 4-1 Asch 生 态 架 构 


上 面 所 有 这 些 代码 库 共 同 组 成 了 Asch 生 态 。 接 下 来 我 们 简单 介绍 一 下 asch 库 以 及 asch-core 库 的 基本 逻辑 ， 其 他 重要 逻辑 会 在 后 面 的 章节 里 详细 解释 。 


4.2 asch 库 简要 解读 


当 我 们 把 asch 库 代码 克隆 下 来 以 后 ， 除 了 启动 文件 、 依 赖 文 件 以 及 相关 测试 文件 之 外 ， 主 要 的 逻辑 代码 都 在 src 目 录 下 。 而 src 目 录 下 又 有 三 个 目录 ， 分 别 存 放 了 Asch 主 链 的 数据 结构 (model) 、 合 约 
(contract) 以 及 接口 (interface) 等 。 文 件 结构 如 下 : 





app.js 
aschd 
build.js 
config.json 
data 
genesisBlock.json 
package.json 
SE 
contract 
basic.js 
chain.js 
gateway.js 
interface 
accounts.js 
agents.js 
model 
account .js 
agent-clientele.js 
agent .js 
asset.js 





4.2.1 数据 结构 





Asch 的 交易 数据 和 区 块 数据 分 别 存储 在 SQLite3 以 及 LevelDB 里 ， 由 asch-smartdb 完 成 和 底层 数据 库 的 交互 。 在 model 目 录 里 则 定义 了 Asch 主 链 的 所 有 数据 结构 。 以 




















户 表 account.js 为 例 : 





module.exports = { 





table: 'accounts', 
tableFields: [ 
{ name: 'address', type: 'String', length: 50, primary key: true, not_ 
null: true }, 
{ name: 'name', type: 'String', length: 20, index: true }, 
{ name: 'xas', type: 'BigInt', default: 0 }, 
{ name: 'publicKkey', type: 'String', length: 64 }, 
{ name: 'secondPublicKey', type: 'String', length: 64 }, 
{ name: 'isLocked', type: 'Number', default: 0 }, 
{ name: 'isAgent', type: 'Number', default: 0 }, 
{ name: 'isDelegate', type: 'Number', default: 0 }, 
{ name: 'role', type: 'Number', default: 0 }, 
{ name: 'lockHeight', type: 'BigInt', default: 0 }, 
{ name: 'agent', type: 'String', length: 50 }, 
{ name: 'weight', type: 'BigInt', default: 0 }, 
{ name: 'agentWeight', type: 'BigInt', default: 0 }, 








在 accounts.js 中 ， 我 们 定义 了 表 名 、 字 段 以 及 字段 的 属性 。 数 据 的 类 型 可 以 是 String、Number、 




















4.2.2 合约 








数据 表 定 义 完成 以 后 ， 如 何 完成 数据 的 读 写 呢 ?” 比 如 新 发 起 一 笔 转 账 操作 ， 如 何 记 录 开 | 数 














Biglnt 等 ， 对 于 String 类 型 的 数据 要 设 








其 他 比较 重要 的 表 还 有 : 记录 了 所 有 交易 的 transactions 表 ， 跨 链 网 关 相关 的 gateway 系 列表 等 。block 表 存储 在 LevelDB 中 ， 在 该 目录 里 没有 体现 。 


























动 时 赋予 了 合约 类 型 。 不 同 的 合约 类 型 有 不 同 的 手续 费 。 所 有 的 合约 都 在 contract 




















录 里 定义 。 我 们 来 看 最 常 








的 转账 合约 的 实现 : 


长 度 ， 同 时 也 可 以 配置 是 否 为 某 个 字段 添加 索引 。 





居 库 中 呢 ? 在 Asch 系 统 里 ， 任 何 一 个 和 区 块 链 进行 交互 的 操作 (一 般 是 写 操作 ) 都 被 抽象 成 了 合约 ， 并 且 在 








ul 





async transfer (amount, recipient) { 
// 一 些 基本 的 条 件 验 证 
if (!recipient) return 'Invalid recipient' 
app.validate('amount', String (amount)) 


amount = Number (amount) 

// 转账 的 主要 逻辑 

const sender = this.sender 
Const senderId = sender.address 





if (this.block.height > 0 && sender.xas < amount) return "Insufficient 


balance'" 
sender.xas -= amount 
let recipientAccount 
if (app.util.address.isNormalAddress (recipient)) { 
recipientAccount = await app.sdb.get('Account', recipient) 
if (recipientAccount) { 
recipientAccount .xas += amount 


} else { 
recipientAccount = app.sdb.create('Account', { 
address: recipient, 
xas: amounty 
name: '', 
Ea 
} 
} else { 


recipientAccount = await app.sdb.getBy('Account', 
if (!recipientAccount) return 'Recipient name not exist' 
recipientAccount .xas += amount 


} 
// 写 入 数据 库 
app.sdb.create('Transfer', { 
七 ia this.trsid, 
senderId, 
recipientId: recipientAccount.address, 
recipientName: recipientAccount.name, 
currency: 'XAS', 
amount: String(amount), 
timestamp: this.trs.timestamp, 
}) 
return null 


}, 


{ name: recipient }) 








其 他 的 合约 也 类 似 ， 合 约 的 类 型 在 asch-core/src/runtime.js 里 注册 。 
@@ 注 总 


这 里 的 合约 和 Asch 最 新 上 线 的 智能 合约 不 是 一 回 事 儿 。 


4.2.3 接口 


Asch 的 HTTP APl 都 在 interface 目 录 里 实现 。 这 些 接口 主要 用 于 通过 HTTP 协 议和 链 上 的 数据 进行 交互 。 接 





回 。 一 个 典型 的 根据 地 址 查询 资产 的 接口 实现 如 下 : 


























的 实现 基于 Node.js 里 非常 流行 的 库 express.js， 可 以 利 




















asch-smartdb 来 查询 数 








居 库 并 返 








router.get ('/:address/:currency', async (req) => { 
// 查询 条 件 
const currency = req.params.currency 
const condition = { 
address: req.params.address, 
currency, 


} 
// 利用 asch-smartdb 和 数据 库 进行 交互 





const balance = await app.sdb.findone('Balance', { condition }) 
if (!balance) return 'No balance' 
if (currency.indexOf('.') !== -1) { 

balance.asset = await app.sdb.findOone('Asset', { condition: 


balance.currency } }) 
} else { 
balance.asset = await app.sdb.findOne('GatewayCurrency', { 
symbol: balance.currency } }) 
} 


return { balance } 


和 


{ name: 


condition: { 








基于 这 种 方式 ， 接 口 可 以 非常 灵活 地 定义 ， 不 同 的 链 可 以 根 











自 定义 接口 。 








4.2.4 配置 文件 


配置 文件 包括 config.json 以 及 genesisBlock.json 等 。genesisBlock.json 里 包含 的 是 创 世 区 块 信息 ， 所 有 节点 的 创 世 区 块 应 该 是 一 致 的 。 节 点 在 启动 时 也 会 验证 这 个 文件 。 而 config.json 则 是 关于 本 节 


























点 的 配置 信息 ， 比 如 端口 、IP、 日 志 级 别 等 。 下 面 就 是 configjson 文 件 的 前 几 项 配置 : 


























"port": 4096, 





// 端 口 


"address": "0.0.0.0"，//IP 地 址 
"publicIp 和 和 // 公 网 IP 地 址 
"logLevel": "debug"， // 日 志 级 别 
"magic": "594fe0f3"， // 主 链 的 magic 值 




















如 果 











4.3 asch-core 库 简要 解读 


asch- 








core 库 的 主要 代码 结构 为 : 


[— base 

[一 block.js 

[一 consensus.js 
-一 transaction.js 
上 一 core 

| 一 accounts .js 

| 一 blocks.js 

[一 chains.js 

[— delegates.js 
[— gateway.js 

| 一 loader.js 

[— peer.js 

[一 round.js 

[一 server.js 

[一 system.js 

| 一 transactions.js 
[一 transport.js 
— via.js 





户 成 功 竞选 成 为 前 101 名 的 话 ， 则 需要 在 secret 字 段 配置 自己 的 主 密码 。 















































asch-core 是 处 理 主 链 主要 逻辑 的 代码 库 ， 源 代码 都 在 src 目 录 ， 还 有 另外 一 个 比较 重要 的 文件 是 proto/index.proto。 其 中 src/initjs 文 件 负责 初 始 化 ， 该 文件 使 用 async:js 来 处 理 异步 调用 问题 ， 可 以 避 
免 回调 地 狱 。 里 面 的 modules 对 应 的 是 src/core/ 下 面 的 模块 ，library.base 对 应 的 是 src/base/ 下 面 的 模块 ， 这 两 个 模块 都 存放 了 区 块 链 的 核心 源码 。 


有 些 文件 名 
core 目 录 则 基本 都 是 对 








src/runtime.js 除 了 加 载 model、 


也 比较 类 似 ， 比 如 block.js 和 blocks.js， 为 什么 要 分 为 两 个 目录 呢 ? 它们 的 关系 
件 触发 函数 ， 注 册 了 许多 onBind 以 及 onNewBlock 之 类 的 事件 回调 函数 。 这 是 它们 的 主要 区 别 。 







































































实 很 简单 ，base 目 录 提供 的 是 一 些 基础 操作 函数 ， 供 其 他 模块 调用 。 自 身 没有 事件 触发 和 回调 函数 。 而 





















































contract 以 及 interface 等 基本 模块 以 外 ， 也 对 app 变 量 进行 初始 化 ， 所 有 的 交易 类 型 也 都 在 这 个 文件 里 注册 。 以 下 是 不 同 合约 类 型 以 及 对 应 的 合约 ID: 





app. 
app. 
app. 
.CcontractTypeMapping[4] 
app. 
app. 
app. 
app. 
app. 
app. 
app. 
.contractTypeMapping[12] 


app 


op 


utils 里 存储 了 相关 的 工 . 


contractTypeMapping[1] 
contractTypeMapping[2] 
contractTypeMapping[3] 


contractTypeMapping[5] 
contractTypeMapping[6] 
contractTypeMapping[7] 
contractTypeMapping[8] 
contractTypeMapping[9] 
contractTypeMapping[10 


contractTypeMapping[11] 


"basic.transfer' 
"basic.setName'" 
"basic.setPassword' 
"basic.1lock' 
"basic.unlock' 
'basic.registerGroup' 
'basic.registerAgent' 
'basic. setAgent' 
'basic.cancelAgent' 


'basic.registerDelegate' 
"basic.vote' 
"basic.unvote' 




















， 其 他 的 





























4.4 Asch 主 链 的 启动 流程 





Asch 主 链 的 启动 过 程 如 图 4-2 所 示 。 
src/core/loader.js。 我 们 先 从 app.js 开 始 介 绍 。 

















录 base/core/gateway 等 存储 了 主 链 的 处 理 逻 辑 ， 我 们 在 这 里 简单 阐述 一 下 受托 人 锻造 和 区 块 的 生产 流程 ， 后 面 的 章节 会 进行 更 加 详细 的 解析 。 























Asch 的 主 程序 可 以 使 用 ./aschd start 或 者 node app.js 的 方式 启动 。 涉 及 的 文件 有 asch 库 的 app.jjs， 以 及 asch-core 库 的 index.js、src/initjs、src/runtime.js 和 


~ srcinitjs: 模块 初始 化 等 








、 src/runtime.js: 合约 、 接 口 等 加 载 








命令 行 配置 相关 选项 





图 4-2 Asch 主 链 的 启动 流程 


4.4.1 app:js 


appjs 可 以 使 用 node app.js 的 方式 启动 ， 并 接收 不 同 的 命令 行 参 数 来 进行 个 性 化 的 配置 ， 例 如 : 





program 
.Version (version) 
.option('-c, --config <path>', "Config file path') 
.option('-~p, --port <port>', 'Listening Port number') 
.option('-~a, --address <ip>', 'Listening host name or ip') 
.option('-g, ‘genesisblock <path>', 'Genesisblock path') 
.option('-x, --peers [peershttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/...]', 'Peers list') 











.option('-l, log <level>', 'Log level') 
.option('-d, --daemon', 'Run asch node as daemon') 
.option('--app <dir>', 'App directory') 

.Option ('--base <dir>', 'Base directory') 
.option('--data <dir>', 'Data directory') 


.Parse (process .argv) 




















可 以 配置 的 项 有 配置 文件 、 端 口 、 节 点 、 数 据 文件 夹 等 。 如 果 用 户 没有 个 性 化 的 配置 ， 则 使 用 默认 配置 。 














接 下 来 ，appjjs 会 进行 主 链 运行 所 需要 的 数据 ， 例 如 : 





appConfig.version = Version 

appConfig.baseDir = baseDir 

appConfig.dataDir = program.data || path.resolve (baseDir, 'data') 

appConfig.appDir = program.app || path.resolve (baseDir, 'src') 

appConfig.buildVersion = 'DEFAULT BUILD TIME 

appConfig.netVersion = process.env.NET VERSION || 'testnet' 

appConfig.publicDir = path.join (baseDir, 'public', 'dist') 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 





如 果 网 络 类 型 是 mainnet， 则 会 写 入 种 子 节点 : 





if (appConfig.netVersion === 'mainnet') { 
const seeds = [ 
757137132, 
1815983436 
] 
for (let i = 0; i < seeds.length; ++i) { 
appConfig.peers.list.push({ ip: ip.fromLong (seeds[i]), port: 81 }) 














最 后 加 载 应 用 并 启动 : 











const asch = require('asch-core') 

const Application = asch.Application 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 
const app = new Application (options) 

app. run() 








这 里 可 以 看 到 ， 其 中 app 是 从 asch.Application 加 载 过 来 的 ， 那 么 这 个 是 在 哪里 定义 的 呢 ? 请 继续 。 


4.4.2 indexjs 


位 于 asch-core 库 根 目录 下 的 index.jjs 用 于 定义 上 节 的 Application。 





首先 ，index.js 会 对 创 世 区 块 进行 验证 : 








function verifyGenesisBlock (scope, block) { 
try { 
const payloadHash = crypto.createHash('sha256') 


for (let i = 0; i < block.transactions.length; ++i) { 
const trs = block.transactions [i] 
const bytes = scope.base.transaction.getBytes (trs) 


payloadHash.update (bytes) 


const id = scope.base.block.getId (block) 
assert.equal( 
payloadHash.digest () .toString('hex'), 
block.payloadHash, 
'Unexpected payloadHash', 
) 


assert .equal (id, block.id, 'Unexpected block id') 

















} catch (e) { 
throw e 
, } 
创 世 区 块 里 包含 的 是 交易 信息 ， 这 些 交 易 信息 会 跟随 创 世 块 被 写 入 区 块 链 。 就 像 中 本 聪 在 比特 
祝 息 。 
indexjs 最 重要 的 部 分 是 Application 类 。 这 个 类 定义 了 一 些 事件 监听 函数 ， 同 时 调用 runtime.js 并 加 载 模 块 : 














的 创 世 块 记录 了 “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” 这 个 





(async () => { 

try { 

await initRuntime (options) 

catch (e) { 

scope.logger.error('init runtime error: 
Process .exit (1) 

Teturn 

} 

scope.bus.message ('bind', scope.modules) 
global .modules = scope.modules 
global.library = scope 


} 


, €) 


scope.1logger.info('Modules ready and launched') 
if (!scope.config.publicIp) { 
scope.logger.warn('Failed to get public ip, block forging MAY not 
work!') 


1) () 




















其 中 ，initRuntime 是 通过 const initRuntime=require ('./src/runtime') 调 


4.4.3 runtimejs 





很 多 的 初始 化 工作 是 在 runtime 中 完成 的 ， 比 如 封装 路 由 、 加 载 数 


以 加 载 合约 为 例 : 


了 src 目 录 下 的 runtime.js。 接 下 来 我 们 来 看 看 runtime.js 主 要 做 了 哪些 事情 。 


居 表 、 加 载 合约 、 加 载 接口 等 。 中 间 还 有 一 系列 的 验证 函数 ， 最 后 定义 了 每 种 交易 类 型 定义 的 合约 编号 。 





async function loadContracts (dir) 
let contractFiles 
try { 
contractFiles 
} catch (e) { 
app.logger.error (“contracts load error: ${e}.) 
return 
} 
contractFiles.forEach( (contractFile) => { 
app.logger.info('loading contract', contractFile) 
const basename path.basename (contractFile, '.js') 
const contractName changeCase. snakeCase (basename) 
const fullpath = path.resolve (dir, contractrFile) 
const contract require (fullpath) 
if (contractFile !== 'index.js') { 
app.contract [contractName] = contract 


{ 


await PIFY (fs.readdir) (dir) 





在 Asch 系 统 里 ， 所 有 的 写 操作 都 是 通过 交易 来 完成 的 ， 而 每 一 种 交易 都 对 应 着 一 个 合约 。 这 里 的 loadContracts 就 是 寻找 所 有 定义 的 合约 并 加 载 : 





app.validate (type, value, constraints) => { 
if (!app.validators[typel]) throw new Error( ` Validator not found: ${type}) 
const error app.validators [type] (value, constraints) 


if (error) throw new Error (error) 














在 Asch 的 其 他 代码 中 ， 我 们 能 经 常 看 到 app.validate 以 及 app.logger 等 用 法 。 读 取 的 都 是 这 里 所 定义 的 方法 。 





44.4 initjs 























日 














要 作用 是 加 载 src/base 和 src/core 里 面 定义 的 模块 ， 使 用 async.auto 解 决 回 
区 块 的 生成 。 但 是 它们 都 有 公共 的 模块 变量 ，moduels 和 library 这 两 


initjs 的 了 
块 为 例 ， 前 者 负责 受托 人 的 锻造 机 制 ， 后 者 负责 





“library 是 之 前 的 init.js 初 始 化 的 合集 ， 比 如 从 library 里 可 以 找到 logger、dbLite 等 。 


* modules 是 stc/core 的 合集 ， 在 里 面 可 以 找到 transactions、accounts 等 。 








Eb 
有 Be: 

















src/core 下 的 各 个 模块 和 src/base 下 的 模块 主要 体 功 





区 别 之 一 是 ，./src/core 模 块 主要 通过 事件 驱动 来 实现 


谈 量 终 
个 变量 贯 


调 问 题 。 src/core/ 这 个 目录 是 整个 Asch 源 码 的 核心 部 分 ， 以 src/core/delegates.js 和 和 src/core/blocks.js 这 两 个 模 


穿 了 整个 核心 逻辑 ， 所 以 需要 先 明 确 这 两 个 变量 的 由 来 : 





base: ['bus', 'scheme', 'genesisblock', 
(outerCallback, outerSscope) => { 
async.auto({ 
bus (cb) { 
cb (nul1，outerScope.bus) 


1 
Scheme (cb) { 
cb (nul1，outerScope.scheme) 
] 
genesisblock(cb) 
cb (nul1， 
] 
consensus: ['bus', 'scheme', 'genesisblock', 
cbl(null, new Consensus (scope)) 
}1, 
transaction: ['bus', 'scheme', ‘'genesisblock', 
cbh(null, new Transaction (scope)) 


}], 


{ block: genesisblock }) 


(cb, scope) => { 


(cb, scope) => { 


block: ['bus', 'scheme', 'genesisblock', 'transaction', (cb, scope) => { 
cb(null, new Block(scope)) 


]]， 
}, outerCallback) 
]]， 

















加 载 src/core 里 面 的 模块 : 

modules: [ 
'network', 'connect', 'config', 'logger', 'bus', 
'sequence', 'dbSequence', 'balancesSequence', 'base', 


(outerCallback, scope) => { 
global.library = scope 
const tasks = {} 
moduleNames .forEach ( (name) => { 
tasks [name] = (cb) => { 
const d = domain.create() 


d.on('error', (err) => { 
scope.logger.fatal (‘Domain ${name}’, { message: err.message, stack: 
err.stack }) 


}) 


d.run(() => { 
scope.logger.debug ('Loading module', name) 
const Klass = require('./core/$ {name}.) 
const obj = new Klass (ch, scope) 
modules .push (obj) 
}) 
’ 
这 
async.series (tasks, (err, results) => { 
outerCallback (err, results) 








在 最 开始 的 appjs 中 ， 调 用 完 initjs 进 行 各 种 初始 化 之 后 ， 后 面 还 有 非常 重要 的 一 步 ， 就 是 触发 onBind 函 数 ， 是 通过 bus.message ("bind') 去 触发 的 。 























对 于 src/core/ 下 面 的 各 个 模块 ， 基 本 上 每 个 模块 都 注册 了 onBind 函 数 ， 但 是 大 部 分 用 处 都 不 大 ， 比 如 accounts 等 模块 的 onBind 函 数 ， 只 是 初始 化 赋值 了 moduels 这 个 变量 而 已 。 

















initjs 里 的 bus.message 是 串联 各 个 核心 模块 的 总 线 。 举 例 说明 : 在 core/delegates.js 中 已 经 注册 了 onBlockchainReady 这 个 回调 函数 。 而 这 个 回调 是 在 core/loader.js 中 通过 
library.bus.message ( “blockchainReady”) ; 去 触发 调用 。 从 src/initjs 代 码 里 可 以 看 出 bus.message 的 实现 ， 可 以 看 到 触发 时 事件 名 字 和 真正 回调 函数 的 映射 关系 是 var 
eventName= ‘on” +changeCase.pascalCase (topic) ; 也 就 是 blockchainReady->onBlockchainReady 的 映射 关系 ， 依 次 类 推 的 还 有 : 


























* blockchainReady->onBlockchainReady 
* newBlock->onNewBlock 


“ bind->onBind 


4.5 ”本 章 总 结 





本 章 首先 介绍 了 Asch 源 代码 库 ， 然 后 介绍 了 Asch 的 启动 流程 。 相 信 经 过 本 章 的 学 习 ， 读 者 可 以 对 Asch 源 代码 的 结构 、 启 动 流程 有 了 一 个 大 概 的 了 解 。 
参考 资料 : 
”asch : 
https://github.com/aschplatform/asch 
* asch-frontend : 
https://github.com/aschplatform/asch-frontend 
* asch-js: 


https://github.com/aschplatform/asch-js 





* asch-cli: 
https://github.com/aschplatform/asch-cli 
* Protocol Buffers-Google's data interchange format: 


https://github.com/protocolbuffers/protobuf 


第 5 章 ”账户 与 安全 


























区 块 链 的 正常 运转 离 不 开 密码 学 的 支持 ， 正 是 因为 利用 了 安全 的 加 密 算 法 ， 区 块 链 上 的 每 一 笔 交易 和 区 块 的 生产 才 有 了 安全 的 保证 。 本 章 先 探索 区 块 链 中 用 到 的 基本 密码 学 算法 ， 然 后 基于 Asch 的 源 代 
码 来 解释 Asch 里 账户 的 生成 与 运 









































5.1 ”区 块 链 里 的 密码 学 























区 块 链 里 涉及 密码 学 的 部 分 主要 是 非 对 称 加 密 算法 以 及 加 密 哈 希 函 数 等 (参见 第 1 章 ) ， 前 者 用 于 公私 钥 的 生成 和 数字 签名 ， 后 者 用 于 生成 地 址 以 及 计算 交易 和 区 块 的 哈 希 值 等 。 

















5.1.1 ， 非 对 称 加 密 


非 对 称 加 密 (asymmetric cryptography) 是 密码 学 的 一 种 算法 ， 在 这 种 算法 里 ， 加 密 和 解密 使 用 不 同 的 密 钥 : 一 个 称 为 公 钥 ， 另 一 个 称 为 私 铀 。 其 中 公 钥 可 以 公开 ， 被 任何 人 获取 。 但 是 私 铀 必须 由 
用 户 严格 保管 ， 不 能 泄露 。 这 对 公私 钥 一 般 是 通过 一 个 随机 大 数字 通过 生成 算法 计算 出 来 的 ， 如 图 5-1 所 示 。 








图 5-1 公私 钥 的 生成 











基于 公开 密 钥 加 密 的 特性 ， 非 对 称 加 密 还 提供 数字 签名 的 功能 ， 签 名 信息 可 以 基于 公 钥 来 验证 。 例 如 ，Alice 用 自己 的 私 钥 对 一 段 信息 进行 签名 ， 那 么 其 他 人 (如 Bob) 就 可 以 借用 Alice 的 公 钥 来 验证 一 
段 信息 是 否 真 的 由 Alice 签 署 ， 同 时 也 不 会 暴露 Alice 的 私 铀 。 如 图 5-2 所 示 。 


























Alice 


Alice 的 私 钥 


Alice 的 公 针 





图 5-2 ”数字 签名 及 验证 





非 对 称 加 密 算法 有 两 个 属性 : 
“ 在 已 知 公 负 的 情况 下 ， 无 法 推导 出 该 公 钥 对 应 的 私 钥 。 
:可 以 通过 某 些 方法 来 证 明 某 人 拥有 一 个 公 钥 所 对 应 的 私 钥 ， 而 此 过 程 不 会 暴露 关于 私 钥 的 任何 信息 。 


常见 的 非 对 称 加 密 算法 有 RSA、ECC (椭圆 曲线 加 密 算法 ，Elliptic Curve Cryp-tography) 等 。 一 般 的 区 块 链 项 目 ， 如 比特 币 、 以 太 坊 ， 都 采用 了 椭圆 曲线 数字 签名 算法 (Elliptic Curve Digital 
Signature Algorithm，ECDSA) ， 原 因 是 在 ECDSA 算 法 里 ， 一 个 长 度 为 256 位 私 钥 的 安全 性 和 RSA 算 法 里 长 度 为 3072 位 私 钥 的 安全 性 一 致 (更 短 的 私 钥 更 加 容易 管理 ) 。 接 下 来 我 们 会 详细 解释 ECDSA 算 
法 的 实现 。 














5.1.2 ”ECDSA 算 法 


在 数学 上 ， 任 何 满足 以 下 方程 的 点 所 形成 的 曲线 称 为 随机 椭圆 曲线 : 


一 X +ax+Db 


并 且 4a3+27b2#0，a 和 b 可 以 为 任意 值 。 图 5-3 是 几 个 随机 椭圆 曲线 的 示例 : 


















































图 5-3 ”随机 椭圆 曲线 示例 





从 图 中 可 以 看 出 ， 每 一 条 随机 椭圆 曲线 都 是 关于 x 轴 对 称 的 。 





ECDSA 算 法 通过 随机 椭圆 曲线 方程 的 性 质 产 生 密 钥 ， 有 好 多 实现 方案 。 其 中 比特 币 、 以 太 坊 以 及 许多 其 他 的 区 块 链 项 目 使 用 的 标准 为 Secp256k1， 它 的 公式 为 : 














y=x3+7 
其 曲线 如 图 5-4 所 示 。 
1. 点 的 加 法 
在 讲解 公私 钥 的 生成 之 前 ,我 们 需要 了 解 在 随机 椭圆 曲线 里 ， 点 的 加 法 是 如 何 实现 的 。 
4 


图 5-4 ”secp256k1 曲 线 图 




















在 随机 椭圆 算法 里 ， 加 法 是 按照 以 下 方式 定义 的 : 假设 曲线 上 存在 两 点 P 和 Q， 那 么 P+Q 的 点 根据 以 下 方式 得 出 : 首先 过 P，Q 两 点 做 直线 ， 然 后 找到 直线 和 曲线 相交 的 第 三 个 点 。 该 点 关于 x 轴 对 称 的 点 
R 就 是 P+Q 的 值 ， 如 图 5-5 所 示 。 



































图 5-5 ”点 的 加 法 


有 了 加 法 以 后 ， 乘 法 的 实现 不 过 是 进行 多 次 加 法 运算 而 已 。 有 了 一 个 基准 点 P 以 后 ， 我 们 可 以 对 其 进行 乘法 运算 ， 最 后 可 以 得 到 曲线 上 的 另外 一 个 点 。 





对 于 secp256k1 来 说 ， 如 图 5-6 所 示 这 个 基准 点 的 坐标 为 : 





x 坐标 
5506 
人 人 本 


Y 坐 标 : 
32670510020758816978083085130507043184471273380659243275938904335757337482424 





5263022277343669578718895168534326250603453777594175500187360389116729240 








图 5-6 ”点 的 乘法 


3. 公 钥 和 私 钥 的 生成 


点 的 运算 满足 结合 律 : 





n:Ptr:P= (ntr) .了 

















因此 对 于 n*P 的 运算 来 说 ， 可 以 利用 结合 律 来 降低 计算 的 次 数 ， 以 10P 为 例 ， 只 需要 计算 4 次 就 可 以 完成 : 





P+P=2 .了 
2 . P+2 . P=4 .了 
4 . P+4.P=8 .了 


2…PH8 PE=10…，P 














假设 随机 取 一 个 0~ 256 位 之 间 的 值 x， 计 算 x*P， 最 后 的 结果 一 定 会 落 在 曲线 上 的 一 点 。 假 设 该 点 为 X， 在 公开 X 以 及 具体 曲线 的 方程 的 情况 下 ， 能 否 反 推 出 来 最 初 的 随机 值 x? 先 说 结论 : 不 能 。 即 使 你 
拥有 超级 计算 机 ， 即 使 你 从 宇宙 诞生 的 一 刻 就 开始 计算 ， 都 不 能 。 下 面 是 论证 过 程 : 


























寻找 x 的 过 程 只 能 通过 暴力 计算 ，x 的 可 能 值 为 0 ~ 2256-1 中 的 一 个 ， 平 均 来 说 需要 计算 2128 次 能 够 找到 一 次 x 值 。 那 运行 一 次 2128 的 计算 需要 多 少时 间 呢 ? 








假设 我 们 使 用 的 是 超级 计算 机 ， 主 频 为 1THz (一 秒 钟 可 进行 一 万 亿 次 运算 ) ， 从 宇宙 诞生 的 那 一 刻 开始 计算 ， 到 现在 也 就 进行 了 298 次 。 找 到 x 值 的 概率 为 298/2128= 1/1073741824。 这 个 概率 和 下 一 
秒 地 球 被 巨型 陨石 撞击 而 毁灭 的 概率 接近 。 既 然 你 已 经 读 到 了 这 里 ， 说 明 这 件 事 并 没有 发 生 。 























在 上 面 的 案例 里 ，x 是 0 ~ 256 位 的 一 个 随机 值 ， 可 以 作为 私 铀 。X 是 随机 椭圆 曲线 上 的 一 个 点 ， 也 就 是 公 钥 。 








至 此 我 们 已 经 证 明了 算法 的 第 一 个 属性 : 在 已 知 公 钥 的 情况 下 ， 无 法 推导 出 该 公 钥 对 应 的 私 钥 。 





接 下 来 证 明 第 二 个 属性 : 可 以 通过 某 些 方法 来 证 明 某 人 拥有 一 个 公 钥 所 对 应 的 私 钥 ， 而 此 过 程 不 会 暴露 关于 私 钥 的 任何 信息 。 具 体 来 说 就 是 ， 如 何 向 别人 证 明 你 知道 x 而 不 暴露 任何 关于 x 的 信息 。 











我 们 首先 对 随机 椭圆 曲线 做 一 些 改动 : 为 了 保证 最 后 计算 出 来 的 点 的 坐标 值 相 加 是 512 位 ，secp256k13 引 入 了 一 个 对 质数 取 模 的 机 制 。 具 体 来 说 ， 随 机 椭圆 曲线 从 








y=x3+ ax+b 
变 成 了 


到 mod p= (x3+ax+b) mod 下 





其 中 p=2256-232-29-28-27-26-24-1， 是 小 于 2256 的 最 大 质数 。 


现在 随机 椭圆 曲线 的 样子 如 图 5-7 所 示 。 





4 数字 签名 


前 面 介绍 过 结合 律 : 





n:Ptr:P= (n+r) .了 














5-7 新 的 随机 椭圆 曲线 





添加 一 个 hash 函 数 ， 简 单 修改 可 以 得 出 : 
hash (m, 1*P) +n:Ptr:P= (hash (m, r* P) *ntr) .了 
使 n*P=X， 那 么 根据 上 节 的 内 容 ，n 为 x。 此 时 方程 简化 为 : 
hash (m，r : P) :Xtr: P= (hash (m，r .了 P) *x+r) .了 
为 了 简单 起 见 ， 我 们 记 R=rP 和 s=hash (m，R) *x+r。 此 时 方程 简化 为 : 
hash (m, R) :+ X+HR=s .了 


上 面 的 方程 是 什么 意思 呢 ? 可 以 这 样 假设 : 在 已 知 m 的 情况 下 ， 如 果 能 够 提供 一 个 S 和 R 满 足 上 面 的 方程 ， 那 么 就 可 以 证 明 一 个 人 拥有 x。 这 个 假设 有 个 前 提 : 如 果 一 个 人 不 知道 x， 那 么 他 就 无 法 提供 R 
和 5 满足 上 面 的 等 式 。 


我 们 来 详细 探讨 一 下 这 个 前 提 : 


如 果 一 个 人 不 知道 x， 又 想 计算 出 S 和 R， 能 够 办 到 吗 ” 结 论 是 不 能 ， 首 先 你 就 无 法 从 hash (m，R) 计算 出 R (在 有 限时 间 内 ) 。 





还 有 一 个 问题 : 在 已 知 R 和 S 的 情况 下 ， 能 和 否 计算 出 关于 x 的 任何 信息 ? 
根据 公式 : 


s=hash (m, R) *xtr 


只 要 解 出 x= (s-r) /hash (m，R) 就 好 了 。 














要 想 计算 出 x， 就 需要 知道 [， 但 是 在 /没有 公开 的 情况 下 ， 有 什么 办 法 可 以 计算 r 吗 ? 我 们 知道 R=r*P;， 但 是 根据 这 个 无 法 倒 推出 r， 所 以 x 也 是 安全 的 。 


至 此 ， 我 们 证 明了 算法 的 第 二 个 属性 : 可 以 通过 某 些 方法 来 证 明 某 人 拥有 一 个 公 钥 所 对 应 的 私 钥 ， 而 此 过 程 不 会 暴露 关于 私 钥 的 任何 信息 。 





5.2 ”Asch 的 账户 生成 流程 





Asch 的 账户 生成 流程 如 图 5-8 所 示 。 
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图 5-8 Asch 的 账户 生成 流程 


52.1 ‘BIP'39 





























如 果 读者 注册 过 Asch 的 钱包 ， 就 会 发 现 用 于 登录 Asch 的 主 密码 是 一 个 由 12 个 英语 单词 组 成 的 字符 串 。 这 来 自 于 BIP39 协 议 ， 该 协议 由 比特 币 社区 首先 在 GitHub 上 提出 。 















































BIP39 描 述 了 使 用 助 记 码 或 者 助 记 句子 (简称 助 记 词 ) 来 生成 确定 性 钱包 的 方案 ， 主 要 为 了 解决 私 钥 难 以 记忆 的 问题 。 所 有 的 助 记 词 都 来 自 于 单词 列表 ， 其 安全 性 也 很 高 。BIP39 由 两 个 部 分 构成 : 1) 
生成 助 记 词 ; 2) 把 生成 的 助 记 词 转化 为 二 进 制 种 子 ， 然 后 利用 这 个 种 子 生成 确定 性 的 钱包 。 












































在 Asch 中 ， 首 先 对 通过 BIP39 算 法 生成 的 助 记 词 进 行 哈 希 运算 ， 得 到 一 个 哈 希 值 ， 然 后 对 这 个 哈 希 值 使 用 ED25519 算 法 生成 一 对 公私 钥 。 然 后 对 公 钥 基于 Base58 进 行 运算 ， 添 加 前 缀 'A' 后 得 到 账户 地 











址 。 代 码 见 asch-core/src/core/accounts.js。 





shared.newAccount = (req, cb) => { 
let ent = Number (req.body.ent) 
if ([128, 256, 384] .indexOf (ent) === -1) { 
ent = 128 
Const secret = new Mnemonic (ent) .toString () 
const keypair = ed.MakeKeypair (crypto.createHash('sha256') .update (secret, 'utf8').digest()) 
const address = self.generateAddressByPublicKey (keypair.publicKey) 
cb(null, { 
secret, 
publicKey: keypair.PublicKey.toString('hex')， 
privateKey: keypair.privateKey.toSstring('hex'), 
address, 


也 














在 生成 一 个 符合 BIP39 要 求 的 主 密码 以 后 ， 我 们 会 对 这 个 主 密码 使 用 SHA256 求 hash 值 。 将 这 个 hash 值 作为 种 子 ， 使 用 ED25519 算 法 生成 密 钥 对 。MakeKeypair 的 实现 方式 如 下 : 

















MakeKeypair (hash) { 
const keypair = sodium.crypto sign seed keypair (hash) 
return { 

publicKey: keypair.publicKkey, 

PrivateKey: keypair.secretKey, 

ks 

} 





generateAddressByPublicKey 这 个 生成 地 址 的 方法 是 怎么 实现 的 呢 ? 代码 里 是 这 么 写 的 : 











Accounts .prototype.generateAddressByPublicKey = publicKey => addressHelper. 
generateNormalAddress (PublicKey) 





实际 代码 为 : 





function generateRawBase58CheckAddress (hashes) { 

if (!hashes || !hashes.length) throw new Error('Invalid hashes') 
let hl = null 
for (let h of hashes) { 

if (typeof h === 'string') { 

h = Buffer.from(h, 'hex') 

} 

hl = crypto.createHash('sha256') .update (h) 
const h2 = crypto.createHash('ripemd160') .update (hl .digest ()) .digest () 
return base58check.encode (h2) 








生成 Base58check 的 地 址 添加 了 一 个 'A' 作 为 前 缀 而 已 。 最 后 生成 的 地 址 格式 类 似 于 APtduJgnXELgwQ66jn9VeHwZMy9kMKckpY。 


5.2.2 ED25519 




















Asch 的 签名 算法 采用 了 ED25519 加 密 算法 。ED25519 公 铀 只 有 32 字 节 ， 签 名 只 有 64 字 节 。 并 且 在 签名 的 过 程 中 不 依赖 随机 数 生成 器 ， 不 依赖 哈 希 函数 的 无 碰撞 性 ， 也 没有 时 间 通 道 攻击 的 问题 。 并 且 
它 的 签名 和 验证 性 能 都 很 高 。Asch 使 用 了 sodium 库 来 完成 签名 与 验证 : 























Const sodium = require('sodium') .api 


module .exports = { 
Sign(hash, keypair) { 
return sodium.crypto sign detached (hash, Buffer.from(keypair.privateKey, 
'hex')) 
}, 


Verify (hash, signatureBuffer, publicKeyBuffer) { 
return sodium.crypto sign verify detached (signatureBuffer, hash, 
publicKeyBuffer) 可 
] 
} 





5.3 ”Asch 的 账户 类 型 














Asch 系 统 里 根据 不 同 的 职能 和 角色 划分 了 不 同 的 账户 类 型 ， 目 前 主要 包括 普通 用 户 、 受 托 人 、 代 理 人 以 及 跨 链 网 关 账 户 等 几 种 类 型 。 





























1. 普 通用 户 















































系统 中 的 绝 大 多 数 用 户 都 是 普通 用 户 。 普 通用 户 除了 拥有 最 基本 的 转账 权利 以 儿 

















还 可 以 通过 锁 仓 获 取 投 票 权 、 发 行 资产 等 操作 。 普 通用 户 也 可 以 把 自己 的 投票 权 转 让 给 代理 人 。 

















普通 用 户 的 数据 都 记录 在 数据 表 accounts 中 : 

















module.exports = { 

table: 'accounts', 

tableFields: [ 
{ name: 'address', type: 'String', length: 50, primary key: true, not 

null: true }, 

{ name: 'name', type: 'String', length: 20, index: true }, 
{ name: 'xas', type: 'BigInt', default: 0 }, 
{ name: 'publicKkey', type: 'String', length: 64 }, 
{ name: 'secondPublicKey', type: 'String', length: 64 }, 
{ name: 'isLocked', type: 'Number', default: 0 }, 
{ name: 'isAgent', type: 'Number', default: 0 }, 
{ name: 'isDelegate', type: 'Number', default: 0 }, 
{ name: 'role', type: 'Number', default: 0 }, 
{ name: 'lockHeight', type: 'BigInt', default: 0 }, 
{ name: 'agent', type: 'String', length: 50 }, 
{ name: 'weight', type: 'BigInt', default: 0 }, 
{ name: 'agentWeight', type: 'BigInt', default: 0 }, 


2. 受 托 人 




















受托 人 是 全 网 共同 选举 出 来 的 101 个 共同 维护 网 络 正 常 运行 的 账户 + 服务 器 节点 。 他 们 也 从 普通 用 户 中 诞生 ， 因 此 基本 数据 也 会 记录 在 accounts 表 里 。 同 时 Asch 还 维护 了 一 个 单独 的 delegates 表 ， 用 了 
记录 受托 人 的 产 块 状态 ， 比 如 得 票 率 、 生 产 块 数 以 及 生产 率 等 : 











module .exports = { 

table: 'delegates', 

memory: true, 

tableFields: [ 

{ name: 'address', type: 'String', length: 50, primary key: true, not_ 

null: true }, 
name: 'tid', type: 'String', length: 64, index: true, not null: true }, 
name: 'name', type: 'String', length: 50, index: true }, 
name: 'publicKey', type: 'String', length: 64, index: true }, 
name: 'votes', type: 'BigInt', index: true }, 
name: 'producedBlocks', type: 'BigInt' }, 
name: 'missedBlocks', type: 'BigInt' }, 
name: 'fees', type: 'BigInt' }, 
name: 'rewards', type: 'BigInt' } 


{ 
{ 
{ 
{ 
{ 
{ 
{ 
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3. 代 理 人 














在 Asch 的 新 版 本 中 有 一 个 新 的 角色 就 是 代理 人 。 代 理 人 可 以 收集 普通 用 户 的 投票 权 ， 作 为 普通 用 户 的 代理 人 行使 投票 选举 出 受托 人 的 权利 。 
































4. 跨 链 网 关 用 户 


























跨 链 也 是 Asch 实 现 的 新 功能 ， 其 中 资产 在 不 同 区 块 链 之 间 的 流通 都 是 由 跨 链 网 关 用 户 来 维护 : 

















module .exports = { 
table: 'gateway accounts', 
tableFields: [ 
{ name: "address'，type: 'String', length: 50, primary key: true }, 


name: 'seq', type: 'Number' , index: true }, 

name: 'gateway', type: 'String', length: 10, index: true }, 
name: 'outAddress', type: 'String', length: 50, index: true }, 
name: 'attachment', type: 'Text' }, 

name: 'version', type: 'Number' }, 

name: 'createTime', type: 'Number' }, 





关于 跨 链 的 实现 部 分 ， 可 以 参考 本 书 的 第 9 章 。 


54 本章 总 结 























至 此 本 章 已 经 介绍 完成 了 Asch 的 账户 体系 的 实现 ， 基 本 上 都 是 对 数据 库 相关 用 户 表 的 增删 改 查 。 这 个 模块 其 实 大 部 分 都 是 常规 API。 读 者 可 以 配合 Asch 库 下 的 src/contract 目 录 一 起 阅读 ， 以 便 更 好 地 
梳理 出 各 种 账户 类 型 的 业务 逻辑 。 




















参考 资料 : 

* bips/bip-0039 

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki 
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:What is the math behind elliptic curve cryptography? 
https://hackernoon.com/what-is-the-math-behind-elliptic-curve-cryptography-f61b25253da3 
Elliptic Curve Cryptography: a gentle introduction 
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* elliptic curves-ECDSA, EdDSA and ed25519 relationship/compatibility 
https://crypto.stackexchange.com/questions/58380/ecdsa-eddsa-and-ed25519-relationship-compatibility 
"ed25519 


http://ed25519.cr.yp.to/ 


第 6 章 ”共识 机 制 























共识 机 制 是 区 块 链 系统 的 灵魂 。 但 是 为 什么 区 块 链 系统 需要 共识 机 制 呢 ? 本 章 将 从 拜占庭 将 军 问 题 谈 起 ， 一 直 谈 到 目前 比较 流行 的 DPoS+PBFT， 这 也 是 Asch 所 使 用 的 共识 算法 。 来 看 看 共识 机 制 解决 
了 哪些 问题 ， 是 如 何 解决 的 ， 最 后 通过 源 代码 解析 来 介绍 Asch 的 共识 机 制 实现 。 








6.1 拜占庭 将 军 问题 














假设 有 9 位 将 军 各 自 带领 军队 去 攻打 一 座 城池 。 为 了 简化 问题 ， 每 个 将 军 可 以 指定 的 作战 计划 分 别 为 进攻 或 者 撤退 ， 并 将 自己 的 决策 通过 信使 传达 到 所 有 其 他 将 军 那里 。 为 了 保证 战略 的 统一 〈 即 达成 决 
策 的 一 致 性 ) ， 各 位 将 军 采用 的 是 少数 服从 多 数 的 策略 ， 即 综合 出 所 有 将 军 的 计划 来 决定 自己 这 支 军队 采取 的 策略 。 












































正常 发 挥 作用 时 的 情况 如 图 6-1 所 示 。 每 位 将 军 都 做 出 进攻 或 者 撤退 的 决策 ， 其 中 5 位 将 军 决定 撤退 ，4 位 将 军 决定 进攻 。 每 个 将 军 都 收 到 了 其 他 将 军 的 决策 。 因 此 根据 少数 服从 多 数 的 原则 ， 每 个 将 军 
做 出 的 决定 都 是 撤退 。 





























如 果 将 军 之 中 混入 了 一 个 间谍 呢 ? 如 图 6-2 所 示 。 这 位 间谍 将 军 可 以 给 不 同 的 将 军 发 送 不 同 的 策略 来 混淆 视听 ， 这 样 就 可 能 破坏 最 终 决策 的 一 致 性 ， 使 得 不 同 的 将 军 采取 不 同 的 策略 ， 来 达到 破坏 军队 的 
目的 。 











图 6-2 有 一 个 间谍 混入 之 后 ， 对 决策 的 影响 




















假设 间谍 将 军 对 4 位 将 军 发 出 了 “进攻 ”的 决策 ， 对 另外 4 位 将 军 发 出 了 “撤退 ”的 决策 。 这 样 的 结果 就 是 最 后 有 四 位 将 军 会 进攻 ， 而 其 他 4 位 将 军 会 撤退 ， 而 进攻 的 4 位 将 军 就 会 陷入 危险 的 境地 。 同 
理 ， 如 果 没 有 间谍 ， 而 信使 被 政 人 截获 的 话 ， 也 可 以 达到 同样 的 效果 。 


























那么 ， 有 没有 一 种 办 法 ， 在 即使 存在 间谍 的 情况 下 依然 能 够 达成 最 后 的 一 致 性 呢 ? 这 就 是 著名 的 拜占庭 将 军 问题 。 目 前 已 经 证 明 的 是 : 如 果 间 谍 的 数量 大 于 或 等 于 总 数 的 三 分 之 一 ， 那 么 拜占庭 将 军 问 
题 是 无 解 的 。 但 是 小 于 三 分 之 一 是 可 解 的 ， 这 种 情况 下 的 算法 也 称 为 拜占庭 容错 算法 (Byzantine Fault Tolerance，BFT) 。 














在 一 个 由 多 个 节点 组 成 的 分 布 式 网 络 里 ， 服 务 器 节点 可 能 被 黑客 攻破 ， 可 能 故意 想 要 作恶 ; 通信 系统 可 能 有 数据 丢失 、 演 示 、 重 复 和 乱 序 的 情况 。 在 区 块 链 系统 里 ， 节 点 还 可 以 任意 地 加 入 或 退出 网 
络 。 这 种 情况 面临 的 问题 其 实 也 是 一 个 拜占庭 将 军 问 题 。 只 不 过 对 应 各 个 将 军 就 是 计算 机 ， 信 使 就 是 通信 系统 ， 被 感染 或 者 故意 作恶 的 计算 机 就 是 间 谈 。 那 么 区 块 链 作为 一 个 复杂 的 分 布 式 系统 ， 是 如 何 解 
决 这 个 问题 的 呢 ? 在 第 1 章 介绍 的 “共识 机 制 ” 已 经 提出 了 多 种 解决 方案 ， 下 面 继续 分 析 这 些 方案 。 





























6.2 ”区 块 链 的 共识 算法 





中 本 聪 在 2008 年 发 明 比 特 币 时 提出 的 共识 机 制 叫 做 工作 量 证 明 (Proof of Work，POW) ， 我 们 一 起 来 看 一 下 这 个 机 制 。 在 比特 币 的 网 络 中 ， 每 个 节点 都 是 平等 的 。 每 个 节点 都 维护 了 一 个 账本 ， 并 且 
因此 最 后 的 账本 可 能 有 多 个 不 同 的 版 本 。 但 是 只 有 在 所 有 人 都 认可 并 掌握 了 同一 个 账本 ， 才 能 保证 系统 数据 的 一 致 性 。 那 在 这 么 多 账本 的 可 能 性 之 间 ， 如 何 决定 哪个 账本 是 有 效 的 呢 ? 

















可 以 参与 记 账 ， 























这 个 就 是 工作 量 证 明 发 挥 作 




















的 时 候 了 。 工 作 量 证 明 算法 里 设置 了 一 个 难度 值 ， 每 个 节点 都 可 以 生产 区 块 ， 但 是 只 有 满足 这 个 难度 值 的 区 块 才 可 以 向 网 络 里 广播 。 而 求解 满足 这 个 难度 值 的 过 程 是 一 个 























暴力 破解 的 过 程 ， 和 节点 的 计算 能 力 成 正比 ， 








因此 一 个 节点 只 有 不 停 地 尝试 去 求解 ， 一 旦 找到 符合 要 求 的 区 块 就 要 立马 广播 到 网 络 里 (因此 其 他 节点 也 可 能 求解 出 来 并 广播 ) 。 其 他 节点 在 收 到 区 块 以 后 会 

















进行 难度 值 的 验证 ， 如 果 发 现 符合 要 求 就 可 以 在 这 个 区 块 的 基础 上 继续 求解 下 一 个 区 块 ， 同 时 也 表示 对 上 一 个 区 块 的 认可 。 








也 被 认为 是 























这 样 的 话 依然 可 能 有 多 个 版 本 (多 条 链 ) ， 
最 安全 的 链 。 大 家 最 终 都 会 认可 的 就 是 这 个 最 长 的 链 ， 通 过 这 种 方式 达到 了 一 致 性 。 














比特 币 实际 上 放弃 了 强 一 致 性 ， 实 现 的 是 最 终 一 致 性 。 





6.3 ”从 DPoS 到 PBFT 


因此 比特 币 的 所 有 节点 还 有 一 条 原则 : 最 长 链 原则 。 就 是 所 有 节点 只 认可 最 长 的 那 条 链 ， 





因为 最 长 的 链 肯定 也 包含 了 最 多 的 工作 量 (计算 量 ) ， 


























工作 量 证 明 算 法 虽然 可 靠 且 安 











， 但 是 效率 比较 低 (比特 币 平均 每 10 分 钟 生产 一 个 区 块 ) ， 并 且 对 能 源 的 浪费 比较 严重 。 在 之 





法 被 提出 来 ， 其 中 2014: 








后 的 区 块 链 发 展 过 程 中 陆续 又 有 不 同 的 共识 




















月 由 当时 的 Bitshares 首 席 开 发 者 Dan Larimer 提 出 并 实现 的 委托 股权 证 明 算 法 (Delegates Proof of Stake，DPoS) 最 为 流行 。 


6.3.1 DPoS 算 法 








己 最 认可 的 10 个 人 来 领导 公司 ， 其 中 每 个 员工 的 票 权 和 他 手 里 持 有 的 股份 




















想象 这 样 一 家 公司 : 公司 员工 总 数 有 1000 人 ， 每 个 人 都 持 有 数额 不 等 的 公司 股份 。 每 隔 一 段 时 间 ， 员 工 可 以 把 手 里 的 票 投 向 

















数 成 正比 。 等 所 有 人 投 完 票 以 后 ， 得 票 率 最 高 的 10 个 人 成 为 公司 的 领导 。 如 果 有 领导 能 力 不 胜 任 或 做 了 不 利于 公司 的 
层 。 这 就 是 对 DPoS 共 识 机 制 的 一 个 形象 描述 。 





DPoS 的 伪 代 码 实现 如 下 : 


for round i // 分 成 很 多 个 round，round 无 限 持续 
dlist i = get N delegates sort by votes // 根 据 投票 结果 选 出 得 票 率 最 高 的 N 个 受托 人 
dlist i = shuffle (dlist i) // 随 机 改变 顺序 
loop 7/round 完 了 ， 退 出 循环 
slot = global time offset / block interval 
pos = Slot % N 
if dlist i[pos] exists in this node //delegate 在 这 个 节点 
generateBlock (keypair of dlist i[pos]) // 产 生 block 


， 那 员工 可 以 撤销 对 该 领导 的 投票 ， 让 他 的 得 票 率 无 法 进入 前 10 名 ， 从 而 退出 管理 


在 Asch 链 系统 中 ， 区 块 链 的 正常 运转 依赖 于 受托 人 (Delegates) ， 这 些 受托 人 是 完全 等 价 的 。 受 托 人 的 职责 主要 有 : 





“ 提供 一 台 节 点 服务 器 并 保证 节点 的 正常 运行 。 

“ 节点 服务 器 收集 网 络 里 的 交易 。 

“ 节点 验证 交易 ， 把 交易 打包 到 区 块 。 

“ 节点 广播 区 块 ， 其 他 节点 验证 后 把 区 块 添加 到 自己 的 数据 库 。 


“ 带领 并 促进 区 块 链 项 目的 发 展 。 








受托 人 的 节点 服务 器 相当 于 比特 币 网 络 里 的 矿 机 ， 在 完成 本 职工 作 的 同时 可 以 领取 区 块 奖励 和 交易 的 手续 费 。 









































一 个 区 块 链 项 目的 受托 人 个 数 由 项 目 发 起 方 决定 ， 一 般 是 101 个 受托 人 。 任 何 一 个 持 币 





户 都 可 以 参与 到 投票 和 竞选 受托 人 这 两 个 过 程 中 。 























户 可 以 随时 投票 、 撤 票 ， 每 个 用 户 投票 的 权重 和 自己 的 持 




















方 决定 ) 个 用 户 成 为 该 项 目的 受托 人 ， 负 责 打 包 区 块 、 维 














的 101 (一 般 为 101， 也 可 以 是 其 他 数字 ， 





体 由 区 块 链 项 

















币 量 成 正比 。 投 票 和 撤 票 可 以 随时 进行 ， 在 每 一 轮 (round) 选举 结束 后 ， 
持 系统 的 运转 并 获得 相应 的 奖励 。 



































户 。 这 101 个 














展 和 运行 最 有 利 的 101 个 








选举 的 根本 目的 是 ， 通 过 每 个 人 的 投票 选举 出 社区 里 对 项 目 发 


























DPoS 共 识 机 制 的 区 块 链 项 目 有 很 多 ， 比 较 知名 的 有 Lisk、EOS、Ark 等 。 








目前 使 








一 个 区 块 链 系 统 只 有 DPoS 的 话 大 部 分 时 间 是 没 问题 的 ， 也 能 达到 最 终 的 数据 一 致 性 。 然 而 它 并 没有 解决 拜占庭 容错 的 问题 ， 如 果 选 举 出 来 的 受托 人 故意 作恶 的 话 依然 会 给 系统 带 来 很 大 的 风险 。 








到 拜占庭 容错 ， 后 来 新 出 的 区 块 链 项 目 一 般 都 会 引入 BFT 方 案 ， 比 如 EOS 的 DPoS+BFT，Asch 的 DPoS+PBFT。 














户 的 服务 器 节点 既 可 以 高 效 维护 系统 的 运转 ， 而 他 们 
展 ， 这 有 点 类 似 于 我 国 的 人 民 代表 制度 (但 是 周期 更 短 、 效 率 更 高 ) 。 通 过 这 种 方式 ， 既 达到 了 去 中 心 化 的 选举 共识 ， 又 保证 了 整个 系统 的 运行 效率 和 减少 能 源 浪费 。 




















己 的 能 力促 进 区 块 链 项 目的 发 





























也 会 贡献 自 





为 了 达 




















Asch 的 101 个 受托 人 是 全 部 开放 给 社区 竞选 的 。 任 何 一 个 持 币 人 都 可 以 在 网 页 钱包 界面 注册 成 为 受托 人 ， 并 








可 到 社区 里 拉票 。 








受托 人 基本 信息 


注册 受托 人 


您 还 不 是 受托 人 





图 6-3 注册 受托 人 


入 口 : 钱包 页 面 -> 区 块 浏览 -> 注册 受托 人 ， 如 图 6-3 所 示 。 





目前 Asch 共 有 600 多 个 持 币 人 注册 成 为 受托 人 ， 但 是 只 有 得 票 率 前 101 的 受托 人 才 有 锻造 区 块 并 领取 奖励 的 权利 ， 如 图 6-4 所 示 。 





最 后 区 块 高 度 jh 2539439 最 后 区 块 时 间 2018/07/09 17:21:10 


受托 人 地 址 

asch_g97 A99CG9fXupHQTCFYCK57or7xWnyUc4w6eM 
asch_063 ANNF36Lkmp782Mdox1URNYUAS9Y92dQfT9T 
asch_096 ASFUvZD4JbYulLy3bmLCSKwdPjrUXUCUDkD 
asch_g66 AP1F9rdXupLcaP95SYq5spQocCren7nTkkc 
asch_g79 APnGGETY7oxMAtyWm2DDdW9WiotUZEX7CYc 
asch_g65 A3zT8FBYMAajUBw4dmeqdmjmb2YqkmvUDr 
asch_g87 AHZZUKZmVCXRxR4NiEQHPanASmbhXHKbh 
asch_g101 APQYC4SSNvsacL3nzPJWPVCE7ITHK9ZTS8z 
asch_g94 AJF9BP2ikziumdy3PcqR79hAT6DLNhy941 
asch_026 A9X68cUZubFcQFnpLKIt499ZUb6oSsN6VZB 
asch_024 Auu4ds2VsaarTh65GPVWfYmm2WvkzMbEE 
asch_048 A79A9CJc9YzG56vRjuSYFdSZZJ6cGZbAH7 
asch_96 ALbG1pkKhj7YWijnjXxGVKbA20qVnUqUrd 


asch_g1 AMasQcwJUJyKbMaZh3r3CGHLB5oB1WqCrW 


口 
口 
口 
口 
口 
口 
口 
口 
口 
口 
口 
口 
口 
口 
口 
口 


asch_082 AJP6k1R9NB27M2qh3WecfBniZRVNa6k2qY 





图 6-4 受托 人 列表 


在 图 中 ， 我 们 可 以 看 到 受托 人 的 排名 、 地 址 、 得 票 率 以 及 生产 率 的 情况 。 





6.3.2 ”PBFT 算 法 


拜占庭 容错 算法 (Practical Byzantine Fault Tolerance，PBFT) 在 1999 年 由 Miguel Castro 和 Barbara Liskov 提 出 ， 解 决 了 原始 拜占庭 容错 算法 效率 不 高 的 问题 ， 将 算法 复杂 度 由 指数 级 降低 到 多 项 
式 级 ， 使 得 拜占庭 容错 算法 在 实际 系统 应 用 中 变 得 可 行 。 

















PBFT 算 法 的 核心 理论 是 : 如 果 有 F 个 故障 节点 ， 那 么 至 少 有 3F+1 个 节点 才 可 以 保证 系统 的 正确 运行 。 理 解 PBFT 算 法 需要 首先 理解 下 面 的 概念 : 











“ 客户 端 (Client) : 请 求 发 起 方 。 在 区 块 链 里 向 主 节 点 发 起 请 求 的 客户 端 节点 ， 在 区 块 链 里 往往 和 主 节点 是 同一 个 。 


“ 副本 (Replica) : 所 有 参与 提供 服务 的 节点 。 在 区 块 链 里 就 是 维护 系统 运行 的 全 节点 。 
“ 主 节 点 (Primary) : 在 副本 中 选 出 的 提供 主要 服务 的 节点 。 在 区 块 链 就 是 区 块 的 生产 者 ， 在 收 到 请 求 以 后 生成 新 的 区 块 并 广播 。 


“ 备份 节点 (Backup) : 主 节点 以 外 的 其 他 节点 。 在 区 块 链 里 是 区 块 的 验证 者 ， 收 到 区 块 以 后 进行 验证 ， 然 后 广播 验证 结果 以 形成 共识 。 





“视图 (View) : 在 一 个 主 节 点 和 多 个 备份 节点 之 间 形 成 的 视图 ， 表 示 对 某 个 区 块 进行 共识 。 











“ 序列 号 (Sequence number) : 由 主 节 点 指定 的 一 个 数字 。 在 区 块 链 里 可 以 理解 为 区 块 高 度 。 


“ 检查 点 (Checkpoint) : 如 果 某 个 序列 号 收 到 了 超过 2/3 的 确认 ， 则 成 为 一 个 检查 点 。 





我 们 接 下 来 一 起 来 看 一 下 通过 PBFT 形 成 共识 的 过 程 (参见 图 6-5) : 











Request , Pre-Prepare ， Prepare , Commit  ， Reply 


Client 


CC Y 
Replica 1 < 一 入 SAM/ 
NN N22// 


Replica 2 NA ES/ 





Replica 3 








6-5 ”PBFT 的 流程 























1) request 阶 段 : 在 通过 DPoS 确 定好 一 个 周期 里 产 块 的 顺序 以 后 ， 每 个 受托 人 都 会 分 配 到 一 个 slot。 受 托 人 轮 询 时 间 检 查 当 前 是 否 是 自己 的 slot， 如 果 是 的 话 就 打包 这 段 时 间 的 交易 ， 生 产 区 块 并 |/ 














。 这 个 受托 人 就 是 上 面 所 说 的 客户 端 和 主 节点 。 








2) pre-prepare 阶 段 : 主 节点 在 生产 区 块 以 后 ， 会 把 自己 生产 的 区 块 广播 给 其 他 节点 。 






































3) prepare 阶 段 : 所 有 其 他 不 产 块 的 受托 人 节点 在 收 到 新 的 区 块 以 后 ， 会 对 其 进行 验证 ， 并 广播 自己 的 验证 结果 。 同 时 每 个 节点 都 等 待 其 他 节点 的 验证 结果 。 





4) commit 阶 段 : 一 个 节点 收 到 其 他 节点 的 验证 消息 后 ， 会 再 次 广播 ， 表 示 确 认 收 到 来 自 2/3 的 节点 的 确认 消息 了 。 














5) reply 阶 段 : 达成 共识 。 























在 整个 过 程 中 ， 为 什么 要 进行 两 次 广播 呢 ? 第 一 次 广播 的 目的 是 为 了 说 明 “我 已 经 收 到 这 个 消息 了 ， 并 且 知 道 另外 也 有 2/3 的 节点 收 到 这 个 消息 了 ”。 第 二 次 广播 是 为 了 说 明 “我 知道 有 2/3 的 节点 对 这 
区 块 进行 确认 了 ”。 











首先 ， 我 们 认为 如 果 最 后 收 到 N-F 个 确认 ， 就 认为 共识 达成 。 考 虑 极端 情况 ， 如 果 所 有 的 间谍 F 都 首先 返回 了 确认 ， 那 么 在 这 N-F 个 节点 里 ， 必 须 有 F+1 个 正常 节点 ， 使 得 F+1>F， 系 统 最 终 才 能 做 出 正 


确 的 判断 。 这 时 还 有 没 返回 确认 的 F 个 正常 节点 ， 这 些 节点 总 量 加 起 来 ， 就 是 F+1 (正常 节点 并 返回 确认 ) 加 F (间谍 节点 并 返回 确认 ) 加 F (正常 节点 未 返回 确认 ) 等 于 3F+1。 


6 
































可 见 ，PBFT 是 利用 通信 次 数 换取 信用 。 每 个 区 块 的 生产 都 需要 节点 间 两 两 交互 去 核验 消息 ， 因 此 通信 代价 非常 高 。 























.4 ”共识 算法 源码 解读 














Asch 采 用 的 共识 算法 是 DPoS+PBFT， 在 Asch 系 统 里 一 个 区 块 的 生产 流程 可 以 概括 如 下 : 


























1) 在 受托 人 A 锻造 区 块 的 时 候 ， 负 责 这 一 次 区 块 锻造 的 受托 人 节点 ， 首 先 需要 用 他 的 签名 创建 votes (createVotes) 。 











但 是 这 个 受托 人 节点 一 般 只 有 一 个 受托 人 密 钥 ， 所 以 不 满足 101x2/3=68 这 个 条 件 ， 无 法 顺利 锻造 这 个 区 块 (hasEnoughVotes) 。 


DN 





3) 所 以 这 个 受托 人 只 好 先 把 这 个 锻造 的 区 块 setPendingBlock 暂 时 寄存 起 来 。 





4) 然后 通过 createPropose 去 广播 给 其 他 受托 人 节点 ， 去 收集 其 他 受托 人 节点 和 该 区 块 有 关 的 签名 。 





5) 其 他 受托 人 验证 这 个 Propose 来 路 之 后 纷纷 响应 ， 把 自己 给 这 个 区 块 的 签名 Votes 发 回 给 一 开始 的 受托 人 A。 

















然后 受托 人 A 一 直 收 集 ， 直 到 收集 到 的 签名 超过 了 101x2/3=68 个 之 后 ， 再 把 刚才 寄存 的 block 通 过 getPendingBlock 取 出 来 。 


Oo 




















7) 继续 完成 这 个 block 的 锻造 。 








共识 算法 在 Asch 的 代码 仓库 里 由 多 个 部 分 组 成 ， 交 易 的 打包 、 区 块 的 新 建 都 算是 共识 算法 的 一 部 分 。 不 过 主要 的 逻辑 都 在 asch-core 里 的 base/consensusjs 和 core/delegates:js 这 两 个 模块 里 ， 区 块 相 


关 的 部 分 会 在 下 一 章 进 行 讲 解 。 下 面 就 介绍 这 两 部 分 源 代 码 。 





6.4.1 base/consensusjs 


























base/consensusjs 这 个 模块 主要 处 理 共 识 相关 的 机 制 。PBFT 算 法 里 的 发 起 提案 、 投 票 确认 等 都 是 在 这 个 模块 完成 的 。 主 要 包含 的 方法 为 创建 投票 、 验 证 票数 、 发 起 提案 等 。 接 下 来 我 们 来 分 析 具 体 的 
代码 。 


1. 创 建 投票 (createVotes) 


创建 投票 的 代码 如 下 : 





Consensus .prototype.createVotes = function (keypairs, block) { 
var hash = this.getVoteHash (block.height, block.id); 
Var votes = { 
height: block.height, 
id: block,id, 
signatures: [] 


keypairs.forEach (function (el) { 
votes.signatures.push ({ 
key: el.publicKey.toString('hex'), 
sig: ed.Sign(hash, el) .toString('hex') 
Ds 
1); 


return votes; 

















先 根据 block 的 高 度 和 id 算 出 hash 值 ， 然 后 使 用 当前 节点 配置 里 合法 的 受托 人 的 密 钥 进 行 签名 ,一般 一 台 服务 端 只 配置 一 个 受托 人 节点 。 最 后 返回 一 个 带 有 当前 block 高 度 、 多 个 受托 人 签名 的 Votes。 















































其 实 ， 这 里 把 Votes 翻 译 成 投票 不 是 非常 合理 。 更 准确 地 说 ，Votes 就 是 受托 人 的 记 账 ， 后 续 会 在 block 生 成 的 时 候 使 用 这 个 Vote 去 验证 ， 包 括 新 生成 一 个 区 块 之 后 ， 广 播 到 其 他 节点 时 需要 广播 区 块 信 
息 和 这 个 Vote 信 息 给 其 他 节点 。 这 样 其 他 节点 都 可 以 验证 这 个 Vote 和 Block， 确 保 Block 的 锻造 过 程 是 由 合法 的 受托 人 通过 正确 的 方式 锻造 出 来 的 。 

















2. 验 证 要 数 (hasEnoughVotes) 











检查 Votes 是 否 包 含 足 够 多 的 受托 人 签名 用 hasEnoughVotes: 








Consensus .prototype.hasEnoughVotes = votes => votes && votes.signatures 
&& votes.signatures.length > slots.delegates * 2 / 3 








目前 受托 人 人 数 是 101， 需 要 的 签名 至 少 101x2/3=68 个 受托 人 。 也 就 是 说 ， 如 果 当 时 在 线 的 受托 人 人 数 不 满 58 人 ， 则 无 法 让 这 个 区 块 链 正常 产 块 。 


3.hasEnoughVotesRemote 





Votes 需 要 包含 至 少 6 个 受托 人 签名 才 行 。 这 个 判断 比 上 面 那 个 hasEnoughVotes 要 求 更 轻 一 些 。 











4.setPendingBlock 





要 理解 这 个 函数 其 实 需要 先 理解 block 的 锻造 过 程 (core/blocks.js， 下 节 介 绍 ) 。 在 block 的 锻造 过 程 中 ， 首 先 会 判断 hasEnoughVotes 是 否 有 足够 的 受托 人 签名 (如 上 所 述 ， 所 需 受托 人 签名 至 少 68 
人 ) ， 但 是 一 般 一 个 受托 人 节点 只 会 有 一 个 受托 人 密 铀 ， 那 其 实 是 在 锻造 的 时 候 是 不 满足 >=68 个 签名 的 要 求 的 ， 所 以 会 先 把 锻造 的 block 先 寄存 起 来 ， 也 就 是 用 setPendingBlock 寄 存 起 来 。 然 后 会 有 
createPropose 并 广播 到 其 他 节点 ， 其 他 节点 收 到 Propose 之 后 会 调用 它们 的 createVotes 生 成 Votes， 然 后 把 votes 发 送 回 来 给 Propose 发 起 者 的 IP。 这 样 ， 发 起 这 个 Propose 的 节点 会 收 到 其 他 节点 的 
votes， 也 就 能 集 齐 超过 68 个 受托 人 的 signatures， 就 有 足够 的 signatures， 则 满足 hasEnoughVotes 的 条 件 ， 然 后 再 把 这 个 PendingBlock 取 出 来 ， 才 真正 完成 这 个 block 的 区 块 锻造 。 













































































这 个 过 程 是 达成 共识 的 一 个 过 程 ， 但 是 在 达成 共识 的 等 待 时 间 里 面 ， 需 要 这 么 一 个 setPendingBlock 存 储 中 间 结 果 的 过 程 。 


5. 发 起 提案 (createPropose) 

















创建 Propose 以 获取 其 他 节点 的 确认 ， 代 码 如 下 : 
Consensus .prototype.createPropose = (keypair, block, address) => { 
assert (keypair.publicKey.toString('hex') === block.delegate) 


Const propose = { 
height: block.height, 
id: block.id, 
timestamp: block.timestamp, 
generatorPublicKey: block.delegate, 
address, 


} 

const hash = self.getProposeHash (propose) 

propose.hash = hash.toString('hex') 

propose.signature = ed.Sign (hash, keypair) .toString('hex') 
return propose 











当 本 节点 发 现 自己 受托 人 签名 不 满足 锻造 区 块 所 需 签名 数量 的 时 候 ， 会 通过 create-Propose 创 建 Propose 并 广播 到 其 他 节点 ， 收 集 其 他 节点 的 受托 人 签名 。 这 是 PBFT 的 一 部 分 。 

















6.4.2 core/delegates.jjs 





core/delegatesjjs 主 要 负责 受托 人 锻造 区 块 的 过 程 之 一 ， 这 个 过 程 是 Asch 的 核心 过 程 。 主 要 涉及 如 何 选 出 当前 轮值 锻造 区 块 的 受托 人 、 一 些 功能 函数 以 及 一 些 和 受托 人 有 关 的 HTTP API 查 询 。 功 能 
数 按照 启动 顺序 依次 为 : 等 待 区 块 链 加 载 完成 (onBlockchainReady) ， 加 载 本 节点 受托 人 (loadMyDelegates) ， 循 环 监听 (loop) ， 确 定 受 托 人 (getBlockSslotData) ， 获 取 受 托 人 列表 (generate 
Delegatelist) 等 。 下 面 分 别 介绍 。 














1.onBlockchainReady 


等 待 区 块 链 加 载 的 代码 如 下 : 








Delegates .prototype.onBlockchainReady = () => { 
priv.loaded = true 


Priv.loadMyDelegates (function nextLoop(err) { 
if (err) { 


library.logger.error('Failed to load delegates', err) 
} 


Priv.loop(() => { 
setTimeout (nextLoop, 100) 
}) 
| 
} 








这 个 函数 基本 上 可 以 算是 core/delegatesjs 模 块 的 入 口 函数 。 





“ 当 区 块 链 从 数据 库 载 入 完毕 之 后 ， 调 用 loadMyDelegates 载 入 受托 人 的 密 钥 对 。 


“ 启动 定时 器 loop 函 数 ， 不 停 地 检查 是 否 轮 到 自己 产 块 ， 如 果 是 ， 则 开始 产 块 。 





接 下 来 展开 讲 这 两 个 过 程 。 
2.loadMyDelegates 


加 载 本 节点 受托 人 列表 ， 代 码 如 下 : 


主要 包含 以 下 两 个 过 程 : 





Priv.loadMyDelegates = (cb) => { 
let secrets = [] 
if (library.config.forging.secret) { 
secrets = util.isArray (library.config.forging.secret) 
? library.config.forging.secret : [library.config.forging.secret] 


return (async () =>{ 
try { 
const delegates = app.sdb.getAll ('Delegate') 
if (!delegates || !delegates.length) { 
return cb ('Delegates not found in db') 
} 
const delegateMap = new Map () 
for (const d of delegates) { 
delegateMap.set (d.publicKey, d) 
for (const secret of secrets) { 
Const keypair = ed.MakeKeypair (crypto.createHash('sha256'). 
update (secret, 'utf8') .digest()) 
const publicKey = keypair.publicKey.toString('hex') 
if (delegateMap.has (PublicKey)) { 
priv.keypairs[publicKey] = keypair 


library.logger.info( ‘Forging enabled on account: ${delegateMap. 


get (publicKey) .address}.) 
} else { 
library.1logger.info (‘Delegate with this public key not found: 
${keypair.publicKey.toString('hex')}.) 


. 

return cb () 
} catch (e) { 

return cb (e) 








上 面 的 代码 主要 包括 如 下 几 个 过 程 : 





1) 从 配置 (比如 config.json) 中 读 取 forging.secret 数 组 ，secret 就 是 Asch 受 托 人 的 密码 (12 个 单词 组 成 ) 。 











2) 通过 secret 计 算出 密 钥 对 ， 














密 钥 对 中 的 公 钥 通 过 getAccount 获 取 账 号 信息 。 




















3) 如 果 该 账号 是 受托 人 ， 则 把 这 个 密 钥 对 加 入 private.keypairs 这 个 全 局 变量 中 ， 并 
俭 查 的 重 


























日 志 之 一 ， 如 果 没 有 这 个 日 志 。 则 代表 可 能 你 的 配置 有 错 。 


所 以 loadMyDelegates 其 实 就 是 private.keypairs 这 个 全 局 变量 的 初始 化 过 程 ， 这 个 全 局 变量 
这 是 锻造 区 块 的 必要 条 件 。 后 面 锻造 区 块 的 时 候 就 需要 用 到 。 























3.loop 





循环 监听 对 受托 人 来 说 是 非常 重要 的 一 个 方法 。 受 托 人 的 服务 器 节点 要 不 停 地 轮 询 ， 查 看 是 否 轮 到 自己 产 块 ， 如 果 产 块 则 进行 下 一 步 的 处 理 。 代 和 码 : 














会 成 功 打出 “Forging enabled on account: ”的 日 志 , 这 


| 四 | 





个 日 志 是 受托 人 搭 于 





服务 器 的 时 候 ， 启 动 节点 后 需 


要 ， 在 private.keypairs 里 面 能 找到 ， 说 明 是 当前 节点 里 面 有 效 的 受托 人 ， 这 里 的 有 效 代表 有 密 钥 对 ， 





Priv.loop = (cb) => { 
if (!Priv.forgingEanbled) { 
library.logger.trace('Loop:', 
return setImmediate (cb) 


"forging disabled') 


} 

if (!Object.keys (priv.keypairs) .length) { 
library.logger.trace('Loop:', 'no delegates') 
return setImmediate (cb) 


} 


if (!priv.loaded || modules.loader.syncing()) { 
library.logger.trace('Loop:', 'node not ready') 
return setImmediate (cb) 


} 


Const currentSlot = slots.getSlotNumber () 

const lastBlock = modules.blocks.getLastBlock () 

// 验证 slot 

if (currentSlot === slots.getSlotNumber (lastBlock.timestamp)) { 
return setImmediate (cb) 


if (Date.now() % 10000 > 5000) { 
library.logger.trace('Loop:', 
return setImmediate (cb) 


} 


"maybe too late to collect votes') 


return priv.getBlockSlotData (currentSlot, lastBlock.height + 1, 
currentBlockData) => { 
if (err || currentBlockData === null) 1{ 
library.logger.trace('Loop:', 'skipping slot') 
return setImmediate (cb) 


i 


(err, 


return library.sequence.add (done => (async () => { 
try { 
if (slots.getSlotNumber (currentBlockData.time) === slots. 
getSlotNumber () 


&& modules.blocks.getLastBlock() .timestamp < currentBlockData.time) { 


await modules.blocks.generateBlock (currentBlockData.keypair, 
currentBlockData.time) 
} 
done () 


} catch (e) { 
done (e) 
}) ()， (err2) => { 
if (err2) { 
library.logger.error('Failed generate block within slot:', err2) 





loop 函 数 主要 做 了 以 下 工作 : 





1) slots.getSlotrNumber 获 取 当 前 slot。 





2) modules.blocks.getLastBlock 获 取 最 新 区 块 。 





3) 通过 getBlockSlotData 找 出 当前 轮 到 哪个 受托 人 锻造 区 块 ， 并 取出 该 受托 人 的 密 钥 对 。 





4) 把 第 三 步 中 取 到 的 受托 人 密 钥 传 入 modules.blocks.generateBlock 进 行 区 块 的 锻造 。 

















总 结 一 下 ，Loop 函 数 最 重要 的 就 是 找 出 当前 需要 锻造 区 块 的 受托 人 ， 然 后 调用 modules.blocks.generateBlock 进 行 区 块 的 锻造 。 至 于 modules.blocks.generateBlock 的 区 块 锻造 过 程 ， 可 以 参考 上 一 
部 分 。 

















4.getBlockSlotData 








getBlockSlotData 方 法 上 








于 确定 受托 人 ， 代 码 如 下 : 











priv.getBlockSlotData = (slot, height, cb) => { 
self.generateDelegateList (height, (err, activeDelegates) => { 
if (err) { 
return cb (err) 
i 
Const lastSlot = slots.getLastSlot (slot) 


for (let currentSlot = slot; currentSlot < lastSlot; currentSlot += 1) { 


const delegatePos = currentSlot % slots.delegates 
const delegateKey = activeDelegates[delegatePos] 


if (delegateKey && priv.keypairs[delegateKey]) { 
return cb(null, { 
time: slots.getSlotTime (currentSlot), 
keypair: priv.keypairs [delegateKey], 
}) 
} 
i 
return cb(null, null) 
}) 
} 





getBlockSlotData 方 法 主要 做 了 以 下 几 步 工作 : 


1) 通过 generateDelegateList 从 数据 库 中 找 出 101 个 vote 数量 最 多 的 账号 公 钥 。 





2) 通过 slots.getLastBlock 获 取 下 一 个 slot， 下 一 个 slot 的 计算 方式 就 是 当前 slot+ 101，101 就 是 受托 人 的 数量 。 





3) 遍历 currentSlot 到 lastSlot 这 101 个 slot， 找 到 第 1 步 中 对 应 的 受托 人 账号 ， 如 果 这 个 受托 人 账号 已 经 在 我 们 的 private.keypairs 注 册 过 ， 则 返回 对 应 的 private.keypairs 中 的 密 钥 对 。 


所 以 这 个 函数 就 是 先 计算 现在 轮 到 哪个 受托 人 锻造 区 块 了 ， 如 果 发 现 当前 需要 锻造 的 受托 人 密 钥 就 在 本 节点 ， 则 取出 该 密 铀 ， 准 备 后 续 的 锻造 工作 。 








5.generateDelegateList 




















generateDelegateList 用 于 获取 受托 人 列表 ， 代 码 如 下 : 





Delegates .prototype.generateDelegateList = (height, cb) => (async () => 1{ 
try { 
const truncDelegateList = self.getBookkeeper () 
Const seedSource = modules.round.calc (height) .toString () 


let currentSeed = crypto.createHash ('sha256') .update (seedSource, "utf8') . 
digest () 
for (let i = 0, delCount = truncDelegateList.length; i < delCount; i++) { 
for (let x= 0; x < 4 && i < delCount; i++, x++) { 
Const newIndex = currentSeed[x] % delCount 
const b = truncDelegateList [newIndex] 
truncDelegateList [newIndex] = truncDelegateList[i] 
truncDelegateList[i] = b 
} 
currentSeed = crypto.createHash ('sha256') .update (currentSeed) .digest () 
} 


cb (nul1，truncDelegateList) 
} catch (e) { 
cbl(‘Failed to get bookkeeper: ${e}.) 


和 二 
generateDelegateList 是 DPoS 的 核心 部 分 ， 主 要 工作 如 下 : 
1) 通过 getKeysSortByVote 从 数据 库 中 找 出 101 个 vote 数 量 最 多 的 账号 公 钥 。 


2) 对 这 101 个 受托 人 公 钥 列表 进行 随机 排序 。 注 意 这 里 的 随机 排序 不 是 完全 随机 ， 与 当前 高 度 有 关 ， 也 就 是 说 ， 对 于 相同 高 度 的 节点 ，generateDelegateList 进 行 随机 排序 后 的 公 钥 列 表 都 是 一 样 的 。 





6.HTTP API 
这 个 部 分 的 API 主 要 有 以 下 这 些 : 
' /count: 返回 当前 受托 人 数量 。 
“ /voters: 投票 给 这 个 受托 人 的 用 户 。 


“ /get: 获取 指定 受托 人 信息 。 


“ /: 获取 受托 人 列表 。 

“ /fee: 注册 受托 人 所 需 的 手续 费 。 

“ /forging/getForgedByAccount: 获取 指定 账户 的 锻造 区 块 信息 。 
“ /forging/status: 获取 指定 账户 信息 的 锻造 是 否 开 启 。 


上 面 的 API 都 挂 在 路 由 /api/delegates 下 。 





还 有 一 些 其 他 方法 : 


“ getActiveDelegateKeypaitrs: 之 前 介绍 的 generateDelegateList 函 数 是 负责 把 当前 排序 靠 前 的 受托 人 获取 出 来 ; 而 getActiveDelegateKeypairs 函 数 是 在 前 者 的 基础 之 上 ， 同 时 把 满足 密 钥 对 能 在 ptivate.keybaits 
找到 受托 人 。 所 以 这 个 函数 返回 的 受托 人 ， 都 是 当前 节点 内 有 锻造 区 块 资格 的 受托 人 。 


:fo 未 : 这 个 函数 名 字 看 上 去 很 可 怕 ， 但 是 其 实 这 个 函数 只 是 在 统计 分 又 的 情况 ， 如 果 发 生 了 发 又 ， 会 把 分 又 原 因 等 信息 写 入 到 forks_stat 数 据 库 中 ， 仅 此 而 已 。 


“ checkDelegates: 这 个 函数 用 于 检查 ， 主 要 是 为 了 保证 每 个 账户 只 能 投 出 最 多 101 票 。 


6.5 ”本 章 总 结 








本 章 的 核心 在 于 ， 理 解 区 块 欠 造 是 如 何 轮 询 触 发 的 ， 当 区 块 锻造 的 时 机 出 现 的 时 候 ， 如 何 挑选 出 当前 应 该 锻造 区 块 的 受托 人 并 进行 区 块 的 生产 。 











参考 资料 : 
* Delegated Proof-of-Stake Consensus : 
https://bitshares.org/technology/delegated-proof-of-stake-consensus/ 
* DPOS Consensus Algorithm-The Missing White Paper: 
https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper 
* Seeking Consensus on Consensus-DPOS or Delegated Proof of Stake and the Two Generals'Problem: 
https://steemit.com/eos/@iang/seeking-consensus-on-consensus-dpos-or-delegated-proof-of-stake-and-the-two-generals-problem 
“ pbft 流 程 深层 分 析 和 解释 : 
https://blog.csdn.net/kojhliang/article/details/71515199 
“EOS 共识 机 制 详解 : 
https://www.jianshu.com/p/6a25099ef5e8 
“ PBFT 实 用 拜占庭 容错 演算 法 深入 详解 : 


https://tw.saowen.com/a/a92ab374b7ce3366948dae182747f662919efd7282dc87cad75ec32470d98a40 


第 7 章 区 块 


局 


记录 上 一 个 区 块 的 哈 希 值 ， 而 自己 区 块 的 哈 希 值 也 会 被 下 一 个 区 块 所 记录 。 通 过 这 种 类 似 于 哈 希 指针 的 方式 把 一 个 一 个 的 区 块 串 联 起 来 ， 共 同 实现 了 防 纂 改 的 功能 ， 如 






































区 块 链 的 数据 结构 


在 详细 讲解 Asch 链 的 源码 之 前 ， 我 们 首先 来 介绍 一 下 区 块 链 的 数据 结构 。 








区 块 是 组 成 区 块 链 的 基本 单位 。 一 个 区 块 的 产生 、 打 包 交 易 、 验 证 以 及 添加 到 区 块 链 上 往往 和 这 个 区 块 链 系 统 采 用 的 共识 机 制 有关。 本 章 主要 介绍 Asch 链 上 区 块 的 锻造 、 验 证 以 及 添加 到 区 块 链 上 等 流 





中 本 陪 在 他 的 论文 《比特 币 : 一 个 点 对 点 的 电子 货币 系统 》 里 介绍 过 区 块 链 的 数据 结构 。 简 单 来 说 ， 每 一 个 区 块 里 打包 了 交易 数据 以 及 区 块 的 元 信息 之 后 ， 会 计算 出 一 个 区 块 的 哈 希 值 。 每 个 















































? 


那 区 块 链 是 如 何 实现 防臭 改 的 


GD 





























图 7-1 所 示 。 








区 块 都 会 





如 果 有 一 个 黑客 想 要 篡改 革 一 个 区 块 的 数据 ， 那 对 这 个 区 块 求 得 的 整体 哈 希 值 就 会 变化 而 被 其 他 节点 发 现 ， 如 图 7-2 所 示 。 如 果 黑 客 想 要 让 这 笔 修改 被 所 有 节点 都 接受 ， 那 他 需要 修改 从 修改 数据 以 后 的 
所 有 区 块 数据 ， 不 然 总 会 有 区 块 里 存储 的 prevBlockHash 和 以 前 的 区 块 对 不 上 。 以 比特 币 为 例 ， 想 要 达成 这 点 必须 要 发 起 51% 攻 击 了 。 
































prevBlockHash prevBlockHash prevBlockHash prevBlockHash 





Genesis Block Block 1 Block 2 Block 3 


图 7-1 区 块 通过 哈 希 指针 形成 的 链 
prevBlockHash 





Genesis Block Block 1 Block 2 Block 3 


图 7-2 ”数据 被 自 改 之 后 的 区 块 链 











阿 希 链 也 采用 了 传统 的 区 块 链 数据 结构 ， 阿 希 链 的 区 块 数据 和 比特 币 一 样 ， 都 存储 在 LevelDB。 


7.2 ”区 块 的 源码 解读 


上 一 章 讲解 了 Asch 共 识 机 制 的 原理 ， 主 要 讲 了 共识 和 受托 人 的 部 分 ， 本 章 会 继续 讲解 区 块 的 相关 逻辑 。Asch 区 块 相关 的 逻辑 主要 在 asch-core 仓 库 的 base/block.js 以 及 core/blocks.js。 产 块 的 逻辑 和 


共识 算法 是 密 不 可 分 的 ， 因 此 想 要 完全 理解 其 中 的 逻辑 ， 需 要 结合 上 一 章 的 内 容 一 起 看 。 





7.2.1 base/blockjs 


这 个 模块 对 外 提供 的 是 一 些 区 块 相关 的 工具 ， 主 要 有 以 下 API: 





:sortTransactions: 排序 待 确认 交易 

“create; 创建 区 块 的 核心 丈 辑 。 

“ sign: 区 块 签名 ， 需 要 用 到 矿工 的 私 钥 。 

“ getBytes: 区 块 的 二 进 制 序列 函数 。 

“ getHash: 根据 区 块 的 二 进 制 序列 后 的 字 节 数组 做 sha256 哈 希 值 。 
“ getId: 用 getHash 进 行 哈 希 计算 后 取 的 十 六 进 制 字符 囊 。 
“verifySignature: 验证 签名 。 

“calculateFee: 计算 手续 党 。 

“ dbSave&dbRead: 数据 库 表 区 块 的 读 写 ， 转 换 。 

“ blockStatus (utils/block-status.js) : 获取 当前 的 区 块 状态 。 
“calcReward: 计算 本 区 块 的 矿工 奖励 ， 只 和 当前 区 块 高 度 有 关 ， 随 着 高 度 越 来 越 高 ， 后 续 奖 励 会 越 来 越 少 。 
:getAddressByPublicKey: 通过 公 角 计算 地 址 ， 常 用 转换 函数 之 一 。 


接 下 来 我 们 讲解 一 





点 API 的 实现 。 





1.sortTransactions 


前 面 介绍 过 ， 每 次 产 块 的 时 候 都 会 打包 当前 未 确认 的 交易 。 但 是 未 确认 的 交易 可 能 有 很 多 ， 那 如 何 确定 交易 的 优先 级 呢 ? 对 交易 的 排序 处 理 就 是 在 这 


“ 设置 二 级 密码 (也 是 一 种 转账 ) 优先 级 最 高 。 


“ 转账 金额 越 高 ， 优 先 级 越 高 。 


代码 实现 如 下 : 





个 方法 里 实现 的 。 具 体 规则 如 下 : 





Block.prototype.sortTransactions = data => data.transactions.sort((a, b) => { 








if (a.type === b.type) { 
if (a.type =—= 1) { 
return 1 
} 
if (b.type === 1) { 


return -1 
a a.type - b.type 
J (a.amount !== b.amount) { 
return a.amount - b.amount 
癌 a.id.localeCompare (b.id) 





2.create 


创建 区 块 的 主要 逻辑 如 下 : 








Block.prototype.create = function (data 
+ 他 用 sortTransactions 对 目 前 从 确 训 总 光 玉 表 进 行 排序 


var transactions = this.sortTransactions (data); 


// 计算 区 块 高 度 : 根据 上 一 个 区 块 的 高 度 + 1 
Var nextHeight = (data.previousBlock) ? data.previousBlock.height + 1 : 1; 
// 根据 区 块 高 度 计算 这 个 区 块 的 奖励 
Var reward = private.blockStatus.calcReward (nextHeight), 
totalFee = 0, totalAmount = 0, size = 0; 





Var blockTransactions = []; 
Var payloadHash = crypto.createHash ('sha256'); 


// 开始 遍历 待 确认 交易 列表 
for (var i = 0; i < transactions.length; i++) { 
Var transaction = transactions[il]; 


// 获取 本 次 交易 的 字 节 数 (普通 转账 交易 的 字 节 数 大 概 是 117) ， 累 加 这 些 字 节 数 


Var bytes = ie aot transaction.getBytes (transaction); ; 


// 如 果 累 加 的 字 节 数 大 于 阔 值 (8M) ， 则 结束 遍历 

if (size + bytes.length > constants.maxPayloadLength) { 
break; 

i 


size += bytes.1length; 
// 累加 遍历 到 的 交易 的 手续 费 ， 转 账 金额 


totalFee += transaction. fee; 
totalAmount += transaction.amount; 


blockTransactions .push (transaction); 
WN 从 芝山 不 关 区 革 Fesi 提 
payloadHash.update (bytes) 7 

} 


let block = { 
version: 0, 
totalAmount: totalAmount, 
totalFee: totalFee, 
reward: reward, 
payloadHash: payloadHash.digest () .toString('hex'), 
timestamp: data.timestamp, 
numberOfTransactions: blockTransactions.length, 
payloadLength: size, 
previousBlock: data.previousBlock.id, 
generatorPublicKey: data.keypair.publicKey.tostring('hex'), 
transactions: blockTransactions 


] 7 


try { 
block.blockSignature = this.sign (block, data.keypair); 


block = this.objectNormalize (block); 
} catch (e) { 


throw Error(e.toString()); 
} 


// 赋值 区 块 变量 并 返回 
return block; 


} 














区 块 里 面 的 主要 字段 如 下 : 





“ version: 目前 是 固定 的 0。 





totalAmount: 累计 打包 交易 的 总 金富 

“ totalFee: 累加 的 打包 交易 的 总 手续 费 。 

“ reward: 本 次 产 块 给 矿工 的 奖励 。 

“ payloadHash: 区 块 hash 值 ， 是 通过 之 前 打包 的 交易 计算 出 来 。 
“ previousBlock: 上 一 个 区 块 的 id。 

“ generatorPublicKey: 该 区 块 生产 者 的 公 钥 。 

"transactions: 打包 的 交易 列表 。 


“blockSignature: 区 块 签名 ， 签 名 需要 用 到 当前 矿工 的 私 钥 ， 并 打包 上 该 区 块 的 主要 信息 中 打出 的 签名 。 





下 面 是 一 个 区 块 的 数据 结构 示例 : 





"version": 0, 
"totalAmount": 99， 
"totalFee": 10000000, 
"reward": 350000000, 
"payloadHash": "807b83f4b85c21a86449a94fce742844eca8144db177307d382870182 
6c16608", 
"timestamp": 53117160, 
"numberOfTransactions": 1, 
"payloadLength": 117, 
"previousBlock": "55399cl0ee7cdb313d40c8f4c87a4253d4590c4fea27d29cefd6025 
6617f£9784", 
"generatorPublicKey": "9423778b5b792a9919b3813e756421ab30d13c4c1743f6ald2aa 
94b60eae60bf", 
"transactions": [ 
{ 
"type": 0, 
"amount": 99, 
"fee": 10000000, 
"recipientId": "15748476572381496732", 
"timestamp": 53117146, 
"asset": { }, 
"senderPublicKey": "8e5178db2bf10555cb57264c88833c48007100748d593570e01 
3c9b15b17004e", 
"signature": "685fc7a43dc2ffb64e87ed5250d546f73e027a81faflbd9d060c6333d 
b37a49b47fbabf1ld5f072b3320f59b0e87be6255808e270£f096d2fd73a3e9d8433d3f0d", 
"id": "807b83f4b85c21a86449a94fce742844eca8144db177307d382870182 
6c16608", 
"senderId": "6518038767050467653" 





i 
] 


1 
lockSignature": "bal4abf575a5edc77972299182cfe7340e87fe4677c23ceccf7bl2e3 
40684126f8b42432fd3a0e262b2cd92b5d0e793804c9cb2e03029ae3ddb1315b74889103" 








上 面 的 区 块 包含 了 一 笔 转账 交易 。 


3.verifySignature 





一 个 节点 在 收 到 其 他 节点 发 送 过 来 的 区 块 以 后 ， 就 会 验证 改 区 块 的 签名 。 








验证 签名 的 代码 如 下 : 





Block.prototype.verifySignature = (block) => { 
const remove = 64 


try { 
const data = self.getBytes (block) 
const data2 = Buffer.alloc (data.length - remove) 


for (let i 
Gata2[i] 


} 

// 生成 哈 希 值 

const hash = crypto.createHash('sha256') .update (data2) .digest () 
const blockSignatureBuffer = Buffer.from(block.signature, 'hex') 
const generatorPublicKeyBuffer = Buffer.from(block.delegate, 'hex') 
// 使 用 ed25519 验证 签名 


return ed.Verify (hash, blockSignatureBuffer || ' ', generatorPublic-KeyBuffer || ' ') 
} catch (e) { 


throw Error(e.toString()) 














验证 签名 的 逻辑 基于 ED25519 算 法 ， 验 证 一 个 区 块 的 公 钥 、 签 名 等 信息 是 否 匹 配 。 


7.2.2 core/blocks.js 








上 一 节 讲 的 是 区 块 的 生产 及 签名 等 过 程 。 为 了 完成 从 区 块 的 生产 以 及 持久 化 的 全 过 程 ， 中 间 还 需要 经 历 共识 的 达成 、 


这 个 模块 主要 提供 了 以 下 API。 








“ generateBlock: 生产 区 块 。 


"onReceiveBlock: 收 到 区 块 事件 后 的 处 理 。 











区 块 的 处 理 等 。 这 一 部 分 的 





点 就 在 于 





区 块 在 共识 中 如 何 传递 、 如 何 持久 化 等 。 








“ onReceivePropose: 收 到 提案 后 的 处 理 ， 这 个 过 程 是 PBFT 算 法 的 一 部 分 。 
" onReceiveVotes: 收 到 投票 后 的 处 理 。 

“ processBlock: 区 块 处 理 。 

1.generateBlock 


先 来 看 生产 区 块 的 代码 : 








Blocks .prototype.generateBlock = async (keypair, timestamp) => { 
if (library.base.consensus.hasPendingBlock (timestamp)) { 
return null 


} 
// 获取 未 确认 交易 列表 
const unconfirmedList = modules.transactions . 
getUnconfirmedTransactionList () 
const payloadHash = crypto.createHash('sha256') 
let payloadLength 
let fees = 0 
for (const transaction of unconfirmedList) { 
fees += transaction.fee 
const bytes = library.base.transaction.getBytes (transaction) 


if ((payloadLength + bytes.length) > 8 * 1024 * 1024) { 
throw new Error('Playload length outof range') 
} 
payloadHash .update (bytes) 
payloadLength += bytes.length 
* 
const height = priv.lastBlock.height + 1 
const block = { 
version: 0, 
delegate: keypair.publicKey.toString('hex'), 
height, 
prevBlockId: priv.lastBlock.id, 
timestamp, 
transactions: unconfirmedList, 
count: unconfirmedList.length, 
fees, 
payloadHash: payloadHash.digest () .toString('hex'), 
reward: priv.blockStatus.calcReward (height), 


} 

// 对 区 块 进行 签名 

block.signature = library.base.block.sign (block, keypair) 
block.id = library.base.block.getId (block) 


let activeKeypairs 


try { 
// 获取 受托 人 密 钥 
activeKeypairs = await PIFY (modules.delegates.getActiveDelegateKeypairs) 
(block.height) 
} catch (e) { 
throw new Error(‘Failed to get active delegate keypairs: ${e}) 


有 


const id = block.id 
assert (activeKeypairs && activeKeypairs.length > 0, 'Active keypairs should 
not be empty') 
library.logger.info(‘get active delegate keypairs len: ${activeKeypairs. 
length}) 
const localVotes = library.base.consensus.createVotes (activeKeypairs, 
block) 
// 验证 签名 是 否 足够 
if (library.base.consensus.hasEnoughVotes (localVotes)) { 
modules .transactions .clearUnconfirmed () 
await self.ProcessBlock (block，{ local: true broadcast: true, votes: 
localVotes }) 
library.logger.info(‘Forged new block id: ${id}, height: ${height}, 
round: ${modules.round.calc (height)}, slot: ${slots.getSlotNumber 
(block.timestamp) }, reward: ${block.reward}.) 
return null 


$ 
// 获取 节点 公 网 IP 地 址 
if (!library.config.publicIp) { 
library.logger.error('No public ip') 
return null 
} 
const serverAddr = `${library.config.publicIp}:${library.config.peerPort} 
let propose 


try { 
// 创建 propose 
propose = library.base.consensus.createPropose (keypair, block, 
serverAgddr) 
} catch (e) { 
library.logger.error('Failed to create propose', e) 
return null 
‘ 
library.base.consensus.setPendingBlock (block) 
library.base.consensus.addPendingVotes (localVotes) 
Priv.proposeCache [propose.hash] = true 
priv.isCollectingVotes = true 
library.bus.message ('newPropose', propose, true) 
return null 


























generateBlock 主 要 是 在 受托 人 产 块 中 被 调用 的 功能 函数 。 受 托 人 产 块 过 程 其 实 已 经 在 上 一 章 里 说 过 ， 是 非常 重要 的 一 个 过 程 。 在 此 可 以 再 梳理 一 遍 整 个 流程 : 


1) 获取 当前 待 确认 的 交易 列表 (最 多 N 个 ) 。 
2) 如 果 当 前 还 有 pendingBlock 的 话 ， 则 说 明 还 没有 达成 共识 ， 则 停止 这 个 产 块 流程 。 


3) 遍历 第 1 步 获取 到 的 待 确认 交易 列表 。 











4) 通过 交易 的 senderPublicKey 从 getAccount 中 获取 该 用 户 信息 。 


























5) 如 果 该 交易 已 经 到 位 (ready) 了 (对 于 多 重 签名 的 交易 ， 需 要 等 到 所 有 签名 都 到 位 才 算 ready) 。 





6) base.transactions.verify 验 证 该 交易 ， 如 果 验 证 通过 ， 则 放 入 ready 数 组 。 








LL 


LS 


7) base.block.create 创 建 面 验证 过 的 交易 列表 。 





区 块 ， 并 且 打 包 步 又 3 




















8) verifyBlock 验 证 新 创建 的 区 块 。 
9) 获取 本 节点 的 受托 人 密 钥 对 。 


10) base.consensus.createVotes 用 这 些 密 钥 对 创建 localVotes。 


11) base.consensus.hasEnoughVotes 检 查 创建 的 votes 是 否 足够 。 
































12) 如 果 votes 足 够 ， 则 顺利 产 块 ; 如 果 不 足够 ， 就 需要 用 createPropose 去 收集 其 他 节点 的 votes， 直 到 达成 共识 。 














2.onReceiveBlock 





区 块 链 里 分 为 产 块 节点 和 同步 节点 。 一 个 同步 节点 在 收 到 区 块 以 后 怎么 处 理 呢 ?这 就 是 onReceiveBlock 要 做 的 事情 。 先 来 看 代码 : 








Blocks .prototype.onReceiveBlock = (block, votes) => { 
if (modules.loader.syncing() || !priv.loaded) { 
return 


if (priv.blockCache[block.id]) { 
return 

: 

Priv.blockCache [block.id] = true 


// 添加 到 序列 
library.sequence.add((cb) => { 
if (block.prevBlockId === priv.lastBlock.id && priv.lastBlock.height + 1 
=== block.height) { 
library.logger.info(‘Received new block id: ${block.id}. + 
~ height: ${block.height}. + 
~ round: ${modules.round.calc (modules.blocks.getLastBlock() .height) } + 
~ slot: ${slots.getSlotNumber (block.timestamp)}.) 
return (async () =>{ 
const pendingTrsMap = new Map () 


try { 
// 获取 交易 列表 
const pendingTrs = modules.transactions. 
getUnconfirmedTransactionList () 
for (const t of pendingTrs) { 
pendingTrsMap.set (t.id, t) 
} 
modules .transactions .clearUnconfirmed () 
await app.sdqb.rollbackBlock() 
await Self.ProcessBlock (block，{ votes, broadcast: true }) 
catch (e) { 
library.1logger.error ('Failed to process received block', e) 
finally { 
for (const t of block.transactions) { 
pendingTrsMap.delete (t.id) 
和 
try { 
const redoTransactions = [http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/.. .pendingTrsMap.values ()] 
await modules.transactions.processUnconfirmedTransactionsAsync (re 四 
doTransactions) 
} catch (e) { 
library.logger.error('Failed to redo unconfirmed transactions', e) 


cb () 
} 
}) () 
} if (block.prevBlockId !== priv.lastBlock.id 
&& priv.lastBlock.height + 1 === block.height) { 


// 分 叉 情 况 下 的 处 理 
modules.delegates.fork (block, 1) 
return cbl('Fork') 
} if (block.prevBlockId priv.lastBlock.prevBlockId 
&& block.height 一 = priv.lastBlock.height 
&& block.id !== priv.lastBlock.id) { 
modules.delegates.fork (block, 5) 
return cb('Fork') 
} if (block.height > priv.lastBlock.height + 1) { 
library.1logger.info (‘receive discontinuous block height ${block. 
height} ) 
modules.1loaqder.startSyncBlocks () 
return cb () 








return cb () 
}) 
i 


在 一 个 节点 收 到 新 区 块 的 时 候 ， 会 有 以 下 几 种 情况 : 





“ 新 区 块 的 父 区 块 就 是 当前 节点 的 区 块 ， 并 且 高 度 也 是 当前 节点 高 度 +1， 说 明 新 区 块 就 是 我 们 要 的 ， 则 调用 processBlock 对 这 个 区 块 进行 后 续 操 作 。 





“ 新 区 块 高 度 是 当前 节点 区 块 高 度 +1， 但 是 父 区 块 不 是 我 们 的 当前 区 块 ， 说 明 发 生 了 分 又 ， 则 调用 module.delegates.fotk 进 行 分 又 记录 。 


“ 新 区 块 的 父 区 块 是 当 





和 节点 区 块 的 父 区 块 ， 高 度 也 是 当前 高 度 ， 说 明 发 生 了 分 又 ， 这 个 新 区 块 就 是 当前 区 块 的 兄弟 区 块 ， 也 调用 module.delegates.fotk 进 行 分 又 记录 ， 但 记录 的 分 又 原因 和 上 一 个 不 同 。 


“ 新 区 块 的 高 度 大 于 当前 节点 高 度 +1， 则 说 明 当 前 节点 的 区 块 高 度 不 够 ， 则 调用 module.loader.startSyncBlocks 进 行 区 块 同步 。 





其 他 情况 则 什么 都 不 做 。 


3.onReceivePropose 





根据 上 一 章 的 内 容 我 们 知道 ， 一 个 节点 在 产 块 的 时 候 需要 发 起 propose， 获 取 其 他 节点 的 确认 才 可 以 进行 接 下 来 的 操作 ， 这 也 是 PBFT 算 法 的 一 部 分 。 





代码 如 下 : 
Blocks .Prototype.onReceivePropose = (propose) => { 
if (modules.loader.syncing() || !priv.loaded) { 

return 


} 
if (priv.proposeCache[propose.hash]) { 
return 


} 


Priv.proposeCache [Propose.hash] = true 


library.sequence.add( (ch) => { 


if (priv.lastPropose && priv.lastPropose.height 一 = propose.height 
&& priv.lastPropose.generatorPublicKey === propose.generatorPublicKey 
&& priv.lastPropose.id !== propose.id) { 


library.logger.warn (“generate different block with the same height, 
generator: ${propose.generatorPublicKey}) 
return setImmediate (cb) 
} 
if (propose.height !== priv.lastBlock.height + 1) { 
library.logger.debug ('invalid propose height', propose) 
if (propose.height > priv.lastBlock.height + 1) { 
library.logger.info (‘receive discontinuous Propose height ${propose. 
height} ) 
modules.1loaqder.startSyncBlocks () 
} 


return setImmediate (cb) 


if (priv.lastVoteTime && Date.now() -~ priv.lastVoteTime < 5 * 1000) { 
library.1logger.debug ('ignore the frequently propose') 


return setImmediate (cb) 
} 
library.logger.info(“receive Propose height ${propose.height} bid 
${propose.id}.) 
return async.waterfall ([ 
// 进行 投票 
(next) => { 
modules.delegates .validateProposeSlot (propose, (err) => { 
if (err) { 
next (‘Failed to validate propose slot: ${err}.) 
} else { 
next () 


library.base.consensus.acceptPropose (propose, (err) => { 
if (err) { 
next (‘Failed to accept propose: ${err}.) 
} else { 
next () 
$ 
}) 
] 
(next) => { 
// 获取 受托 人 密 钥 
modules .delegates .getActiveDelegateKeypairs (propose.height, (err, 
activeKeypairs) => { 
if (err) { 
next (“Failed to get active keypairs: ${err}) 
} else { 
next (null, activeKeypairs) 
下 
}) 
}, 
(activeKeypairs, next) => { 
if (activeKeypairs && activeKeypairs.length > 0) { 
const votes = library.base.consensus.createVotes (activeKeypairs, 
propose) 
library.1logger.debug (‘send votes height ${votes.height} id ${votes. 
id} sigatures ${votes.signatures.length}.) 
// 发 送 投票 
modules .transport .sendVotes (votes, propose.address) 
priv.lastVoteTime = Date.now() 
priv.lastPropose = propose 
} 


setImmediate (next) 


if (err) { 
library.logger.error (“onReceivePropose error: S${err}.) 
library.1logger.debug ('onReceivePropose finished') 
cb () 
}) 
}) 
} 





onReceivePropose 是 共识 达成 的 过 程 之 一 。onReceivePropose 先 会 做 如 下 异常 检查 : 
“ 如 果 新 的 propose 高 度 和 当前 propose 高 度 一 致 但 是 id 不 一 致 ， 则 打出 warn 日 志 。 
“ 新 propose 高 度 不 等 于 当前 propose 高 度 +1， 则 认为 是 无 效 。 进 一 步 ， 如 果 新 propose 高 度 大 于 当前 propose 高 度 +1， 认 为 是 无 效 的 同时 ， 还 会 调用 modules.loader.startSyncBlocks 开 始 同步 区 块 。 
“ 如 果 最 新 一 次 vote 的 时 间 (这 里 的 vote 就 是 对 propose 的 投票 ) 在 5 秒 之 内 ， 则 认为 propose 过 于 频繁 ， 忽 略 。 


如 果 以 上 检查 都 通过 ， 则 开始 走 下 面 流程 : 








bus.message (“newPropose”...) 发 出 新 propose 来 临 的 事件 。 
2) modules.delegates.validateProposeSlot 验 证 此 propose slot 是 否 有 效 。 
3) base.consensus.acceptPropose 接 受 这 个 新 propose。 


4) modules.delegates.getActiveDelegateKeypairs 获 取 本 节点 的 受托 人 密 钥 对 。 





5) base.consensus.createVotes 使 用 本 节点 的 受托 人 密 钥 对 创建 对 propose 的 投票 。 


6) 把 vote 发 送 给 propose 发 起 者 。 























这 里 的 votes 和 用 户 通过 在 线 钱包 对 受托 人 进行 投票 不 是 同一 个 含义 ， 需 要 区 分 清楚 。 











4.onReceiveVotes 











在 其 他 节点 对 某 个 要 生产 的 区 块 进行 投票 以 后 ， 产 块 节点 需要 随时 处 理 投票 的 情况 。 如 果 票 数 足够 的 话 则 进行 区 块 处 理 。 








代码 如 下 : 
Blocks .prototype.onReceiveVotes = (votes) => { 
if (modules.loader.syncing() || !priv.loaded) { 
return 
} 


library.sequence.add((cb) => { 
const totalVotes = library.base.consensus.addPendingVotes (votes) 
if (totalVotes && totalVotes.signatures) { 
library.logger.debug (“receive new votes, total votes number 
${ftotalVotes .signatures .Length} ) 


} 
// 验证 是 否 有 足够 的 票数 
if (library.base.consensus.hasEnoughVotes (totalVotes)) { 
const block = library.base.consensus.getPendingBlock () 
const height = block.height 
const id = block.id 
return (async () =>{ 
try { 
modules .transactions .clearUnconfirmed () 
await self.ProcessBlock (block，{ votes: totalVotes, local: true, 
broadcast: true }) 
library.logger.info(‘Forged new block id: ${id}, height: ${height}, 
round: ${modules.round.calc (height)}, slot: ${slots. 
getSlotNumber (block.timestamp)}, reward: ${block.reward}.) 
} catch (err) { 
library.logger.error (“Failed to process confirmed block height: 
${height} id: ${id} error: ${err}.) 


cb () 
]) () 


return setImmediate (cb) 

















这 个 方法 主要 做 了 两 件 事 : 








“ base.consensus.addPendingVotes 把 收 到 的 票 先 暂 存 起 来 。 
“ base.consensus.hasEnoughVotes 判 断 目 前 收 到 的 票 是 否 已 经 足够 。 如 果 已 经 有 足够 的 票 了 ， 则 base.consensus.getPendingBlock 把 之 前 暂 存 的 区 块 再 拿 出 来 ， 开 始 进行 区 块 处 理 (processBlock) 。 
5.processBlock 


产 块 节点 在 收集 到 足够 的 票数 以 后 ， 接 下 来 要 怎么 处 理 呢 ? 代码 如 下 所 示 : 





Blocks .Prototype.ProcessBlock = async (b, options) => { 
if (!priv.loaded) throw new Error('Blockchain is loading') 


let block = b 
app.sdb.beginBlock (block) 


if (!block.transactions) block.transactions = [] 
if (!options.local) { 
try { 
block = library.base.block.objectNormalize (block) 
} catch (e) { 
library.logger.error( “Failed to normalize block: ${e}‘, block) 
throw e 


} 
// 验证 区 块 
await self.verifyBlock (block, options) 


library.logger.debug('verify block ok') 

if (block.height !== 0) { 
Const exists = (undefined !== await app.sdb.getBlockById (block.id)) 
if (exists) throw new Error(“Block already exists: ${block.id}.) 

} 


if (block.height !== 0) { 
try { 
await PIFY (modules.delegates.validateBlockSlot) (block) 
} catch (e) { 
library.logger.error (e) 
throw new Error(‘Can't verify slot: ${e}) 
} 
library.logger.debug ('verify block slot ok') 
} 


for (const transaction of block.transactions) { 
library.base.transaction.objectNormalize (transaction) 

} 

Const idList = block.transactions.map(t => t.id) 

if (await app.sdb.exists('Transaction', { id: { $in: idList } })) { 
throw new Error('Block contain already confirmed transaction') 


} 


app.1logger.trace('before applyBlock') 

te 
2 self.applyBlock (block, options) 

} catch (e) { 
app.1logger.error( ‘Failed to apply block: ${e}) 
throw e 

} 

} 


try { 
self.saveBlockTransactions (block) 
await self.applyRound (block) 
await app.sdb.commitBlock () 
const trsCount = block.transactions.length 
app.1logger.info (‘Block applied correctly with ${trsCount} transactions ) 
self.setLastBlock (block) 


if (options.broadcast) { 
options.votes.signatures = options.votes.signatures.slice(0, 6) 
library.bus.message ('newBlock', block, options.votes) 
F 
library.bus.message ('processBlock', block) 
} catch (e) { 
app.1logger.error (block) 
app.1logger.error('save block error: ', e) 
await app.sdb.rollbackBlock () 
throw new Error (` Failed to save block: ${e}.) 
} finally { 
priv.blockCache = {} 
priv.proposeCache = {} 
priv.lastVoteTime = null 
Priv.isCollectingVotes = false 
library.base.consensus.clearState () 











要 有 以 下 步骤 : 


processBlock: 











1 base.block.sortTransactions 排 序 区 块 的 交易 列表 。 














2) 用 verifyBlock 进 行 验证 区 块 。 


3) 数据 库 里 查询 该 block 信 息 ， 如 果 block 已 存在 则 报错 返回 。 








4) 用 modules.delegates.validateBlockSslot 验 证 区 块 slot， 如 果 验 证 没 通过 ， 则 记录 这 次 是 分 又 ， 并 报错 返回 。 





5) 从 数据 库 查询 该 交易 信息 ， 如 果 交 易 已 存在 则 报错 返回 。 











6) 用 base.transactions.verify 验 证 该 交易 。 








7) 执行 applyBlock 使 该 区 块 生效 。 





processBlock 的 最 后 一 步 是 调用 applyBlock 继 续 对 区 块 进行 处 理 。applyBlock 的 代码 如 下 : 











Blocks .prototype.applyBlock = async (block) => { 
app.1logger.trace('enter applyblock') 
const appliedTransactions = {} 
// 处 理 交 易 
try { 
for (const transaction of block.transactions) { 
if (appliedTransactions[transaction.id]) { 
throw new Error(‘Duplicate transaction in block: ${transaction.id}.) 


await modules.transactions.applyUnconfirmedTransactionAsync (transaction) 


appliedTransactions [transaction 


} 
} catch (e) { 
app. logger .error (e) 
await app.sdb.rollbackBlock () 
throw new Error(‘Failed to apply block: ${e}.) 


.id] = transaction 





首先 验证 交易 是 否 存 在 ， 如 果 没 有 交易 则 调 

















所 以 每 次 产生 区 块 的 函数 调用 过 程 是 : 

















generateBlock -> processBlock -> applyBlock 


modules.transactions.applyUnconfirmedTransactionAsync (transaction) 处 理 。 





7.3 ”本 章 总 结 





“ Asch 代 码 仓 库 : http://github.com/AschPlatform/ 


第 8 章 交易 


在 上 一 章 里 ,我 们 介绍 了 








部 分 的 代码 量 更 多 ， 本 章 会 介绍 Asch 交 易 相关 的 详细 流程 。 


8.1 





Asch 上 的 交易 类 型 


在 Asch 系 统 里 ， 所 有 对 区 块 链 进行 写 操作 (除了 打包 区 块 ) 的 过 程 都 可 以 抽象 为 某 一 类 的 交易 ， 比 如 投票 
主要 如 下 。 





“ basic: 基本 类 型 ， 包 括 转账 、 设 置 昵称 、 锁 仓 、 设 置 二 级 密码 等 。 


区 块 的 生产 流程 是 Asch 链 系统 中 的 核心 流程 。 本 章 介 绍 的 与 区 块 相关 的 各 种 流程 在 上 一 章 的 共识 机 制 里 也 有 所 涉及 。 建 议 读者 将 这 两 个 部 分 一 起 阅读 ， 

















区 块 创建 的 核心 流程 ， 而 交易 的 核心 流程 和 区 块 如 出 一 略 ， 只 不 过 交易 是 更 泛 化 的 概念 ， 含 义 比较 广 ， 可 以 代表 转账 、 投 票 等 类 型 ， 








:uia: 创建 自 定义 资产 相关 ， 包 括 注册 发 行商 、 发 行 资产 、 资 产 转 账 等 。 


. chain: 注册 DApp 应 用 链 相关 ， 包 括 注册 应 用 、 替 换 受 托 人 、 对 应 用 的 充值 和 提现 等 。 


“ proposal: 提案 相关 。 


“ gateway: 跨 链 网 关 相 关 ， 共 同 维护 跨 链 交易 的 建立 。 


“ group: 理事 会 相关 ， 包 括 激活 、 增 加 成 员 、 赫 换 成 员 等 。 


“ contract: 智能 合约 相关 ， 包 括 合 约 的 注册 、 调 用 和 支付 等 。 


“ exchange: Bancor 锚 定 相关 。 


上 面 所 有 的 交易 类 型 都 可 以 在 asch-core 仓 库 的 src/runtime.js 文 件 里 进行 查询 : 


app. 
app. 
app. 
app. 
app. 


np 
app 


app. 
app. 
app. 
app. 
app. 


contractTypeMapping[1] = 'basic. 
contractTypeMapping[2] = 'basic. 
contractTypeMapping[3] = 'basic. 
contractTypeMapping[4] = 'basic. 
contractTypeMapping[5] = "basic. 
.contractTypeMapping[6] = 'basic. 
.contractTypeMapping[7] = 'basic. 
contractTypeMapping[8] = 'basic. 
contractTypeMapping[9] = 'basic. 


contractTypeMapping[10 
contractTypeMapping[11] 
contractTypeMapping[12] 


"basic 
"basic 


、 锁 仓 、 设 





会 对 共识 机 制 和 区 块 相关 的 流程 有 一 个 更 清楚 的 


区 别 在 于 转账 的 类 型 以 及 参数 不 同 。 交 易 


二 级 密码 等 ， 普 通 的 转账 也 只 不 过 是 其 中 一 个 类 型 的 交易 而 已 。Asch 的 交易 类 型 





transfer' 
SetName' 
SetPassword' 
lock' 

unlock' 
registerGroup' 
registerAgent' 
setAgent' 
cancelAgent' 


'basic.registerDelegate' 


ate’ 
.unvote' 





对 每 种 交易 类 型 ， 都 需要 哪些 参数 呢 ? 在 asch 仓 库 的 asch/src/contract 

















回 导 


回 


) ， 就 可 以 获取 到 每 种 交易 类 型 的 参数 。 


8.2 ”交易 的 生命 周期 及 其 实现 





区 块 链 虽 然 是 由 一 个 一 个 的 
































录 里 ， 根 据 不 同 的 交易 类 型 查找 到 对 应 的 合约 (注意 ， 这 个 目录 里 的 合约 与 由 























区 块 组 成 的 ， 但 是 区 块 里 面 的 交易 才 赋予 了 








1) 创建 交易 。 








2) 广播 交易 ， 把 交易 广播 到 区 块 链 网 络 。 








3) 验证 交易 ， 由 其 他 节点 验证 交易 。 











区 块 链 意义 。 一 笔 交 易 从 创建 到 最 终 被 打包 到 





区 块 可 以 分 为 以 下 几 个 过 程 : 

















户 开发 的 部 署 在 Asch 主 链 上 的 智 


台 6 会 ， 
BE 


约 不 是 一 


4) 写 入 区 块 链 。 





交易 相关 的 代码 基本 上 在 asch-core 仓 库 的 src/base/transaction.js 和 src/core/transactions.js 两 个 模块 。 接 下 来 我 们 会 分 析 交 易 在 整个 委 


8.2.1 创建 交易 





创建 交易 的 代码 在 src/base/transaction.js 模 块 ， 具 体 代码 如 下 : 


Transaction.prototype.create = (data) => { 
Const trs = { 
type: data.type，// 交易 类 型 
senderId: data.senderId，// 发 起 人 





senderPublicKey: data.keypair.PublicKey.toString('hex')，// 发 起 人 的 公 钥 


timestamp: slots.getTime () ，// 时 间 惟 
message: data.message，// 备注 
args: data.args，// 参数 
fee: data.fee, // 交易 费 
mode: data.mode，// 交易 模式 
} 


const signerId = addressHelper.generateNormalAddress (trs.senderPublicKey) 


if (transactionMode.isDirectMode (trs.mode)) 
trs.senderId = signerId 
} else if (transactionMode.isRequestMode (tr 


{ 


s.mode)) 1{ 


if (!trs.senderId) throw new Error('No senderId was provided in request 


mode') 
trs.requestorId = signerId 
} else { 
throw new Error('Unexpected transaction mr 
} 
// 签名 交易 
trs.signatures = [self.sign(data.keypair, t: 


if (data.secondKeypair) { 


ode ') 


rs)] 


trs.secondSignature = self.sign (data.secondKeypair, trs) 


} 
trs.id = self.getId(trs) 


return trs 











创建 交易 (这 里 的 交易 是 泛 指 ， 含 转账 、 设 置 密码 、 投 票 等 类 型 ) ， 具 体 类 型 可 以 在 attachAssetType 里 配置 。 

















这 里 需要 注意 的 是 : 创建 交易 的 过 程 既 可 以 在 服务 端 完成 ， 也 可 以 在 客户 端 完 成 。 如 果 需 要 在 服务 端 创建 交易 的 话 ， 那 么 用 户 需要 把 自己 的 私 钥 通过 网 络 传输 到 服务 端 。 而 网 络 环境 并 不 是 安全 的 ， 因 


此 这 种 方式 有 风险 。Asch 在 asch-js 模 块 提供 了 客户 端 本 地 创建 交易 的 方法 。 用 户 在 本 地 创建 完 交 易 以 后 可 以 把 签名 好 的 交易 发 送 给 服务 端 来 验证 ， 这 是 一 种 更 安全 的 方式 。 使 


下 
const doTransaction = (address, amount) => { 
// 创建 交易 
const password = 'your master password' 
const secondPassword = 'password' 
Const message = 'you message' 





























const transaction = asch.transaction.createTransaction (address, amount*1e8, 


message, password, secondPassword); 


const reqData = JSON.stringify({"transaction":transaction}); 


// 封装 交易 
const post options = { 
host: 'mainnet.asch.io', 
Port; “SD 
path: '/peer/transactions', 
method: 'POST', 
headers: { 
'Content-Type': 'application/json', 
'Content-Length': reqData.length, 
'version':'', 
'magic':'5f5b3cf5"' 
} 
} 


Var post req = http.request (post_options, function(req, res) { 


Var html = "''; 

req.on('data', function (data) { 
html += data; 

ys 

req.on('end', function () { 
json = JSON.parse (html); 

Hs 

DD); 


// post the data 
post_ req.write (reqData); 
post_req.end(); 


E 命 周期 里 的 代码 实现 。 


























asch-js 创 建 





交易 的 代码 如 




















交易 的 签名 比较 简单 ， 就 是 使 用 用 户 的 私 钥 然后 
































SHA256 算 法 对 交易 进行 签名 。 


Transaction.prototype.sign = (keypair, trs) => { 
const hash = crypto.createHash('sha256') .update (self .getBytes (trs, true, 


true)) .digest () 


return ed.Sign(hash, keypair) .toString('hex') 


} 








上 面 的 代码 展示 了 如 何在 本 地 创建 交易 并 签名 ， 接 下 来 这 笔 交 易 就 需要 广播 出 去 了 。 


8.2.2 广播 交易 








一 个 节点 在 创建 完 交 易 以 后 就 会 把 这 笔 交 易 广播 给 其 他 的 节点 。 其 他 节点 在 收 到 这 笔 交 易 后 ， 会 首先 加 入 到 本 节点 的 Transaction Pool 然 后 进行 处 理 。 








在 asch-core 的 src/core/transactions.js 的 addTransactionUnsigned 方 法 里 ， 交 易 在 创建 完 以 后 会 产生 一 个 事件 : 





library.bus.message ('unconfirmedTransaction' 


这 个 事件 被 监听 到 以 后 ， 会 对 交易 进行 广播 : 





Transport .prototype.onUnconfirmedTransaction 


, trs) 


= (transaction) => { 


Const message = { 
body: { 
transaction: JSON.stringify (transaction), 
}, 
} 
self.broadcast ('transaction', message) 


} 











其 他 节点 收 到 广播 过 来 的 交易 以 后 ， 就 需要 进行 验证 了 。 


8.2.3 ”验证 交易 


一 笔 交易 的 验证 分 为 好 多 个 部 分 ， 首 先 会 验证 交易 的 时 间 戳 、 交 易 费 、 类 型 和 参数 等 ， 然 后 会 对 交易 的 签名 进行 验证 。 


以 下 是 基本 的 验证 逻辑 : 





Transaction.prototype.verify = async (context) => { 
const { trs, sender, requestor } = context 
// 验证 时 间 截 
if (slots.getSlotNumber (trs.timestamp) > slots.getSlotNumber()) { 
return 'Invalid transaction timestamp'" 


| 
// 验证 类 型 
if (!trs.type) { 
return "Invalid function' 


} 

// 验证 交易 费 

const feeCalculator = feeCalculators[trs.type] 

if (!feeCalculator) return 'Fee calculator not found' 
const minFee = 100000000 * feeCalculator (trs) 

if (trs.fee < minFee) return 'Fee not enough' 


trey 4 
// 根据 交易 的 类 型 选择 合适 的 函数 对 签名 进行 验证 
Const bytes = self.getBytes (trs, true, true) 
if (trs.senderPublicKey) { 
const error = self.verifyNormalSignature (trs, requestor, bytes) 
if (error) return error 
} else if (!trs.senderPublicKey && trs.signatures && trs.signatures. 
length > 1) { 
Const ADDRESS TYPE = app.util.address.TYPE 
const addrType = app.util.address.getType (trs.senderId) 
if (addrType ADDRESS TYPE.CHAIN) { 
const error await seIf.verifyChainSignature (trs, sender, bytes) 
if (error) return error 
} else if (addrType === ADDRESS TYPE.GROUP) { 
Const error = await self .verifyGroupSignature (trs, sender, bytes) 
if (error) return error 
} else { 
return 'Invalid account type' 





} 
} else { 
return 'Faied to verify signature' 


} 

} catch (e) { 
library.logger.error('verify signature excpetion', e) 
return 'Faied to verify signature' 

} 

return undefined 


} 





验证 签名 的 函数 有 : verifyNormalSignature、verifyChainSignature、verifyGroupSignature 等 ， 验 证 逻辑 基本 类 似 ， 我 们 来 看 最 简单 的 verifyNormalSignature 的 代码 : 


Transaction.prototype.verifyNormalSignature = (trs, requestor, bytes) => { 
if (!self.verifyBytes (bytes, trs.senderPublicKey, trs.signatures[0])) { 
return 'Invalid signature'" 
机 
if (requestor.secondPublicKey) { 
if (!trs.secondSignature) return "Second signature not Provided' 
if (!self.verifyBytes (bytes, requestor.secondPublicKey, trs. 
secondSignature)) { 
return 'Invalid second signature' 
} 
} 


return undefined 




















原理 基本 上 是 先 对 交易 做 基本 的 验证 ， 如 果 用 户 设置 二 级 密码 的 话 再 进行 二 次 验证 。 








8.2.4” 写 入 区 块 链 











交易 在 验证 通过 以 后 ， 接 下 来 就 是 处 理 交 易 准 备 写 入 区 块 了 。 处 理 交易 的 流程 主要 由 src/core/transactions,js 里 的 processUnconfirmedTransactionAsync 和 applyUnconfirmedTransactionAsync 函 
数 来 完成 。 基 本 逻辑 是 验证 完 以 后 调用 src/baseVtransaction,js 里 的 apply 函 数 。 我 们 来 看 一 下 apply 函 数 的 实现 : 
































Transaction.prototype.apply = async (context) => { 
Const { 
block, trs, sender, requestor, 
} = context 
// 获取 合约 名 称 
const name = app.getContractName (trs.type) 
if (Iname) { 
throw new Error (‘Unsupported transaction type: S${trs.type} ) 
上 
const [mod, func] = name.split('.') 
if (Imod || !func) { 
throw new Error('Invalid transaction function') 
机 
const fn = app.contract [mod] [func] 
if (!fn) { 
throw new Error('Contract not found') 


} 


if (block.height !== 0) { 
// 根据 交易 模式 进行 不 同 的 处 理 
if (transactionMode.isRequestMode (trs.mode) && !context.activating) { 
const requestorFee = 20000000 
if (requestor.xas < requestorFee) throw new Error('Insufficient 
requestor balance') 
requestor.xas -= requestorFee 
app.addRoundFee (requestorFee, modules.round.calc (block.height) ) 
// trs.executed = 0 
app.sdb.create ('TransactionStatu'，{ tid: trs.id, executed: 0 }) 
app.sdb.update('Account', { xas: requestor.xas }, { address: requestor. 
address }) 


Peturan 


if (sender.xas < trs.fee) throw new Error('Insufficient sender balance') 
sender .xas -= trs.fee 
app.sdb.update('Account', { xas: sender.xas }, { address: sender.address }) 


Const error = await fn.apply(context, trs.args) 
if (error) { 
throw new Error (error) 
} 
} 





























在 apply 函 数 中 ， 主 要 是 调用 app.sdb.update 对 用 户 余额 做 相应 的 增 减 等 操作 。 
































交易 在 验证 处 理 完 以 后 ， 怎 么 写 入 数据 库 呢 ? 这 里 其 实 是 利用 了 asch-smartdb 的 功能 。 代 码 如 下 : 











try { 

app.sdb.beginContract () 

await library.base.transaction.apply (context) 
app.sdb.commitContract () 

catch (e) { 

app.sdb.rollbackContract () 
library.logger.error (e) 

throw e 





如 果 交 易 正常 ， 就 提交 到 | 数据 库 里 (这 里 是 SQLite) ， 而 如 果 有 问题 的 话 就 会 回 滚 交 易 。 





8.3 ”本 章 总 结 














在 区 块 链 中 ， 交 易 代表 的 含义 比较 广 ， 可 以 代表 转账 ， 也 可 以 代表 投票 等 。 每 种 交易 有 不 同 的 逻辑 ， 但 是 核心 流程 和 区 块 差不多 : 序列 化 ， 进 行 哈 希 计算 hash， 签 名 ， 验 证 等 等 。 本 章 的 内 容 可 以 帮助 
大 家 认识 Asch 链 中 处 理 交 易 的 细节 ， 大 家 在 设计 自己 的 交易 模型 时 也 可 以 作为 参考 。 




















参考 资料 : 


“Asch 代 码 仓库 : https://githmb.com/AschPlatform/ 
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如 今 ， 区 块 链 之 间 的 彼此 隔离 成 为 了 区 块 链 技术 应 用 和 资产 流通 的 阻碍 。 跨 链 技术 是 把 区 块 链 技术 从 目前 一 个 个 分 散 的 孤岛 中 相连 接 的 良药 ， 也 是 区 块 链 之 间 进 行 相互 通信 的 桥梁 。 无 论 是 公有 链 还 是 
私有 链 ， 跨 链 技术 都 是 实现 价值 互联 网 的 关键 。 跨 链 技术 的 必要 性 早已 经 在 链 圈 达成 了 共识 ， 而 不 是 要 不 要 做 的 问题 中 。 在 本 章 中 ， 我 们 将 一 起 来 探索 各 种 跨 链 技 术 ， 以 及 Asch 的 跨 链 实 现 原理 。 








9.1 ” 跨 链 技术 的 提出 与 探索 





2016 年 9 月 份 ， 以 太 坊 的 创始 人 Vitalik 给 R3 提 供 的 跨 链 技 术 报 告 里 ， 他 提出 了 三 种 跨 链 的 方案 : 公证 人 模式 、 中 继 模式 以 及 哈 希 锁定 模式 ， 参 见 表 9-1。 


表 9-1 Vitalik 提 出 的 三 种 跨 链 模式 


中 继 模式 哈 希 锁定 模式 


所 有 《需要 所 有 链 上 都 | pe 
本 有 中 继 ， 否 则 只 支持 单 向 ) 个 交叉 依赖 


a 链 不 会 失败 或 者 受到 | 链 不 会 失败 或 者 受到 “51% 
信任 模型 多 数 公证 人 诚实 ‘st mei i 











使 用 跨 链 交 换 
支持 (需要 共同 的 长 期 


让 - 持 \ 支 持 
使 用 跨 链 资产 转移 公证 人 信任 ) 不 支持 


哈 希 锁定 模式 
不 直接 支持 
大 多 数 支 持 但 是 有 难度 






适用 路 链 Oracles 
适用 跨 链 资产 抵押 
多 种 币 智 能 














合约 


接 下 来 我 们 分 别 来 介绍 这 三 种 模式 。 


1. 公 证 人 模式 


公证 人 模式 (Notary) 很 好 理解 ， 




































































一 个 现实 世界 的 例子 比喻 。 假 设 A 和 B 没 有 建立 信任 关系 ， 然 而 C 是 A 和 B 都 信任 的 第 三 方 ， 那 就 可 以 引入 C 充 当 公证 人 作为 中 介 。 这 样 的 话 ，A 和 B 就 可 以 建立 间接 的 




































































信任 关系 。 
采用 公证 人 模式 比较 有 代表 性 的 方案 是 Interledger， 如 图 9-1 所 示 。 它 本 身 不 是 一 个 账本 ， 不 寻求 任何 的 共识 。 这 个 模式 中 ， 一 笔 交 易 要 从 发 送 者 到 接收 者 ， 需 经 过 四 层 : 应 用 层 、 传 输 层 、 账 本 交互 
屋 、 账 本 层 、 这 里 的 核心 是 一 个 顶层 加 密 托管 系统 称 为 “连接 者 ” ， 在 连接 者 的 帮助 下 (用 账本 交互 协议 上 LP) ， 资 金 在 各 账本 (如 L1 和 L2) 间 流 动 。 这 种 方案 的 好 处 很 好 理解 ， 同 时 缺点 也 很 明显 。 这 种 模 
式 和 区 块 链 的 去 中 心 化 理念 存在 一 些 冲 突 ， 所 以 很 多 人 不 认为 它 是 区 块 链 ， 而 更 多 是 一 种 中 心 化 的 产物 。 
发 送 者 接收 者 
应 用 层 SPSP SPSP 
传输 层 PSK pSK 
连接 者 : 连接 者 (N -1 实例)  : 
账本 交互 层 ILP ILP : : ILP. : : ILP 
账本 层 L1 插件 一 一 L1 插件 L2 插件 …:: L2 插件 : : LN 插件 :: LN 插件 
图 9-1 Interledget 的 跨 链 实现 
2. 中 继 模式 
中 断 模 式 (sidechains/relays) 是 目前 跨 链 技 术 应 用 比较 多 、 相 对 复杂 的 方式 。 一 般 来 说 ， 主 链 不 知道 侧 链 的 存在 ， 而 侧 链 必须 要 知道 主 链 的 存在 。 











中 继 模式 比较 有 代表 性 的 是 Polkadot 中 继 链 。 在 Polkadot 的 实现 里 ， 其 他 的 平行 链 (比如 以 太 坊 ) 通过 转 接 桥 和 Polkadot 中 继 链 相 连 。 用 户 提 交 一 个 交易 后 ， 收 集 人 进行 收集 并 广播 。 这 笔 交易 到 了 


中 继 链 以 后 ， 会 再 经 过 几 次 路 由 ， 找 到 正确 的 平行 链 以 后 ， 最 后 交 由 平行 链 处 理 。 通 过 这 种 方式 完成 了 交易 的 跨 链 ， 如 











9-2 所 示 。 





一 一 交易 
(外 部 参与 者 提交 ) 
ee e 广播 交易 


收集 人 ~ r 
， 提交 候选 区 块 


广播 区 块 一 5 
钓鱼 人 四 
平行 链 社 区 -一 

账户 
进入 的 交易 





验证 人 集群 
(按照 他 们 所 在 的 平行 链 着 色 ) ”2 级 中 继 链 







跨 链 交易 
(由 验证 人 管理 ) 


出 去 的 交易 


平行 链 平行 链 
队列 和 I/O 


虚拟 的 平行 链 
(例如 以 太 坊 ) 





9-2 Polkadot 中 继 链 




















Polkadot 采 用 了 一 些 比较 有 技巧 性 的 办 法 ， 即 多 重 签名 的 机 制 ， 把 主 链 资产 进行 锁定 ， 在 侧 链 上 锚 定 、 执 行 ， 在 侧 链 上 的 交易 是 通过 多 重 签名 共同 投票 决定 交易 是 否 有 效 。Asch 在 实现 跨 链 技术 时 ， 也 
是 采用 多 重 签名 的 联合 验证 机 制 ， 因 此 也 属于 此 类 。 
































3. 哈 希 锁定 模式 
丛 希 锁定 模式 (Hash-locking) 起 源 于 比特 币 闪电 网 络 ， 闪 电网 络 本 身 是 一 种 小 额 交 易 的 快速 支付 手段 ， 后 来 有 人 把 它 的 关键 技术 哈 希 时 间 锁 合约 应 用 到 跨 链 技 术 上 。 虽 然 哈 希 锁定 模式 实现 了 跨 链 资 
产 的 交换 ， 但 是 没有 实现 跨 链 资产 的 转移 ， 更 不 能 实现 这 种 跨 链 合约 ， 所 以 它 的 应 用 场景 是 相对 比较 受 限 的 。 





























4 三 种 跨 链 模式 的 对 比 
接 下 来 我 们 从 支持 的 跨 链 类 型 、 信 任 模 式 、 是 否 支 持 跨 链 资产 交换 和 资产 转移 ， 以 及 能 否 支 持 跨 链 合约 和 资产 抵押 等 方面 简单 对 比 一 下 这 三 种 模式 。 
“ 从 跨 链 类 型 上 看 ， 公 证 人 模式 是 双向 的 跨 链 ， 而 中 继 模 式 有 的 支持 双向 ， 有 的 支持 单 向 ， 而 哈 希 锁定 模式 是 一 种 依赖 关系 。 
“ 从 信任 模型 上 看 ， 公 证 人 模式 需要 多 处 公证 人 的 证 实 ， 这 也 是 最 为 人 诉 病 的 地 方 ， 公 证 人 是 第 三 方 、 特 权 机 构 ， 很 容易 成 为 整个 系统 信任 环节 中 最 弱 的 那 一 环 。 


“ 公证 人 模式 和 中 继 模式 均 能 支持 跨 链 资产 交换 及 转移 、 跨 链 合约 和 资产 抵押 。 而 哈 希 锁定 模式 支持 的 功能 比较 少 ， 能 够 支持 跨 链 资产 交换 ， 大 部 分 场景 能 够 支持 资产 抵押 ， 但 不 支持 跨 链 资产 转移 和 














事实 上 ， 跨 链 资产 交换 和 资产 转移 的 意义 比较 重大 ， 现 今 网 络 运行 速度 较 低 ， 手 续费 很 高 ， 而 通过 跨 链 资产 转移 ， 我 们 可 构建 一 个 更 高 效 、 低 成 本 的 网 络 。 实 现 跨 链 资产 转移 的 直接 结果 就 是 跨 链 智能 
合约 实现 ， 既 然 所 有 的 资产 已 经 转 到 同一 个 链 上 ， 那 么 智能 合约 的 实现 就 非常 容易 了 。 





9.2 ”比特 币 多 签名 交易 的 实现 











比特 币 采 用 的 是 基于 多 签名 交易 的 跨 链 实现 ， 利 用 对 方 公 链 的 多 签名 系统 实现 了 跨 链 网 关 ， 属 于 上 面 所 说 的 中 继 模式 。 本 部 分 主要 探讨 比特 币 上 多 签名 交易 的 实现 ， 下 一 节 (9.3 节 ) 将 介绍 Asch 如 何 基 
于 比特 币 的 名 签名 交易 机 制 实现 跨 链 。 在 其 他 的 类 比特 币 系统 (如 LiteCoin、ZCash、Asch 等 ) 里 ， 相 关 原 理 和 比特 币 一 致 。 























9.2.1 _m-of-n 多 签名 交易 的 脚本 





在 比特 币 的 脚本 系统 里 ， 一 个 m-of-n 的 多 签名 脚本 由 以 下 几 个 部 分 组 成 : 








Pubkey script: OP_HASH160 <Hash160 (redeemScript)> OP FEQUAL 
Redeem script: <m> <A pubkey> [B pubkey] [C pubkeyhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/...] <n> OP_CHECKMULTI 
Signature script: OP 0 <A sig> [B sig] [C sighttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/...] 











其 中 ，m 和 In 必须 是 OP_1 ~ OP_16 的 其 中 之 一 。 需 要 注意 的 是 ， 签 名 的 顺序 必须 要 和 Redeem Script 里 的 公 钥 顺 序 一 致 ， 否 则 验证 的 时 候 会 失败 。 而 由 于 历史 原因 ， 脚 本 最 开始 要 放置 一 个 额外 的 值 ， 
一 般 放 置 OP 0。 





9.2.2 ”多 签名 脚本 的 执行 


首先 来 看 一 下 在 比特 币 中 ， 多 签名 脚本 是 如 何 执行 的 ， 代 码 如 下 : 











Pubkey script: OP HASH160 <Hash160 (redeemScript)> OP EQUAL 
Redeem script: <OF 2> <C pubkey> <B pubkey> <A pubkey> <OP 3> OP 

CHECKMULTISIG 加 站 
Signature Script: OP 0 <B sig> <A sig> <redeemScript> 





拼接 后 的 完整 脚本 如 下 : 





OP 0 <B sig> <A sig> OP 2 <C pubkey> <B pubkey> <A pubkey> OP 3 








运行 过 程 如 下 : 

Sig Stack Pubkey Stack (Actually a single stack) 
B sig C pubkey 

A sig B pubkey 

OP 0 A pubkey 


1. B sig compared to C pubkey (no match) 
2. B sig compared to B pubkey (match #1) 
3. A sig compared to A pubkey (match #2) 





成 功 。 有 两 个 签名 验证 通过 。 











验证 多 签名 使 用 的 是 OP_CHECKMULTISIG。 它 首先 会 找到 第 一 个 签名 ， 然 后 和 每 一 个 pubkey 进 行 验证 ， 一 旦 成 功 ， 就 继续 下 一 个 验证 ， 直 到 所 有 的 验证 都 通过 或 者 验证 失败 。 如 果 一 个 pubkey 验 证 
失败 ， 则 OP_CHECKMULTISIG 在 后 面 的 验证 过 程 里 就 不 会 再 使 用 这 个 pubkey， 所 以 签名 的 顺序 一 定 要 和 脚本 里 的 一 致 。 


























如 果 签 名 顺序 不 对 会 怎样 呢 ? 我 们 来 看 一 个 示例 。 


完整 脚本 : 





OP 0 <B sig> <A sig> OP 2 <A pubkey> <B pubkey> <C pubkey> OP 3 








运行 过 程 

Sig Stack Pubkey Stack (Actually a single stack) 
A sig C pubkey 

B sig B pubkey 

OP 0 A pubkey 


1. A sig compared to C pubkey (no match) 
2. A sig compared to B pubkey (no match) 





失败 。 两 个 签名 ， 只 有 一 个 验证 通过 。 


9.2.3 ”比特 币 里 实现 多 签名 交易 


接 下 来 我 们 在 比特 币 的 全 节点 上 演示 一 下 多 签名 交易 的 实现 。 





1. 生 成 新 地 址 


这 里 我 们 生成 三 个 比特 币 地址 : 








root@iZ2zeb4wal7uttyf80bcriZ:~# bitcoin-cli getnewaddress 
mpFLSDjCcxekrrcdQd62kyUrPHiAGck8mx 
root@iZ2zeb4wal7uttyf80bcri2Z:~# bitcoin-cli getnewaddress 
mxUZ5SQfEcmCHSb8KNnsDs26byEtSdwbv23 
root@iZ2zeb4wal7uttyf80bcriZ:~# bitcoin-cli getnewaddress 
mylkprdpM17PZJNB55GwJS5AZzLGjx9isHh9 





2. 获 取 新 地 址 的 公 钥 


代码 如 下 : 





root@iZ2zeb4wal7uttyf80bcriZ:~# bitcoin-cli validateaddress mpFLSDjCcxekrrcdQ 
d62kyUrPHiAGCk8mx 

{ 
"isvalid": true, 
"adgdress": "mpFLSDjCcxekrrcdQd62kyUrPHiAGCck8mx", 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 
"pubkey": "03b91ff254ae3bb386le4a6c16ab356d6c52ccfd2b58bedf0dda84657dfd9d9afc", 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


} 


root@i22zeb4wal7uttyf80bcri2:~# bitcoin-cli validateaddress mxUZ25SQfEcmCHSb8K 
nsDs26byEtSdwbv23 

{ 
"isvalid": true, 
"address": "mxUZ5SQfEcmCHSb8KnsDs26byEtSdwbv23", 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


"pubkey": "039f1475fb37d91ed65765c897acbdc37da3a7abal19f5b8ad5ff22a95 
4e8350798", 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


} 


root@iZ2zeb4wal7uttyf80bcri2Z:~# bitcoin-cli validateaddress mylkprdpM17PZJNB5 
5GwJ5AzLGjx9isHh9 

{ 
"isvalid": true, 
"address": "mylkprdpM17PZJNB55GwJ5AzLGjx9isHh9", 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


"pubkey": "030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e52644febf", 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 





3. 生 成 多 签名 地 址 








利用 上 面 一 步 获 取 到 的 三 个 公 钥 ， 就 可 以 生成 多 签名 地 址 了 。 注 意 redeemScript， 在 后 面 的 操作 中 还 会 用 到 它 : 











root@iZ2zeb4wal7uttyf80bcri2Z:~# bitcoin-cli createmultisig 2 ''"' 


"03b91ff254ae3bb3861le4a6c16ab356d6c52ccfd2b58bedf0dda84657dfd9d9afc", 
"039f£1475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22a994e8350798", 
"030ee8793fa2cb93f0cfd475b990cbaa48a28dq83bd8f434348607368e52644febf" 
J 
{ 

"address": "2MzSwUwBclxuNHwRotwrdFugLvju8VV9uPT™", 

"redeemScript": "522103b91ff254ae3bb3861e4a6c16ab356d6c52ccfd2b58bedf0ddqa84 
657dfd9d9afc21039f1475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22a9 
94e835079821030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e5264 
4febf53ae" 














也 可 以 使 用 “两 个 公 钥 + 一 个 地 址 ”来 生成 多 签名 地 址 ， 产 生 的 结果 一 样 : 

















root@i22zeb4wal7uttyf80bcri2Z:~# bitcoin-cli createmultisig 2 "7 


"mpFLSDjCcxekrrcdQd62kyUrPHiAGck8mx", 
"mxUZ5SQfEcmCHSb8KNsDs26byEtSdwbv23", 
"030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f£f434348607368e52644febf" 


J 


"address": "2MzSwUwBclxuNHwRotwrdFugLvju8VV9uPT™", 

"redeemScript": "522103b91ff254ae3bb386le4a6c16ab356d6c52ccfd2b58bedf0dda84 
657dfd9d9afc21039f1475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22a9 
94e835079821030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e5264 
4febf53ae" 





需要 注意 的 是 ， 如 果 Pub key 的 顺序 不 一 致 ， 则 生成 的 结果 也 不 一 样 : 





root@iZ2zeb4wal7uttyf80bcriZ:~# bitcoin-cli createmultisig 2 ''" 
[ 
"039f1475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22a994e8350798", 
"03b91ff254ae3bb3861e4a6c16ab356dq6c52ccfd2b58bedf0dda84657dfd9d9afc"， 
"030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e52644febf" 


J 


"adgdress": "2MwaiMGy43UjopAcpcqL8PiuezKcPyQKgHh", 

"redeemScript": "5221039f1475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22 
a994e83507982103b91ff254ae3bb386le4a6c1l6ab356d6c52ccfd2b58bedf0dda8465 
7dfd9d9afc21030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e5264 
4febf53ae" 





所 以 一 定 要 记 住 自己 在 生成 多 签名 地 址 时 的 公 钥 排序 。 
4 转账 到 多 签名 账户 


代码 如 下 : 





rooteiZ2zeb4wal7uttyf80bcri2:~# bitcoin-cli sendtoaddress 2MzSwUwBclxuNHwRotw 
rdFugLvju8VV9uPT 0.001 
8c67e4d3264696d222d5a72c70c8806eb3f12b9a02dlbc80554ab00803be86c0 





返回 值 为 txid。 
5 .根据 txid 查 询 交易 信息 


根据 转账 的 txid， 可 以 查询 详细 的 交易 信息 。 我 们 需要 这 里 的 hex 信 息 ， 用 于 后 面 进一步 解码 : 





root@iZ2zeb4wal7uttyf80bcri2:~# bitcoin-cli gettransaction 8c67e4d3264696d222 
qd5a72c70c8806eb3f12b9a02dlbc80554ab00803be86c0 
{ 





-0.00100000, 
"fee": -0.00000446, 
"confirmations": 0, 
"trusted": true, 
"txid": "8c67e4d3264696d222d5a72c70c8806eb3f12b9a02d1lbc80554ab00803be86c0", 
"walletconflicts": [ 
]， 
"time": 1504079526, 
"timereceived": 1504079526, 
"bip125-replaceable": "no", 
"details": [ 

{ 





"amount": -0.00100000, 
Wout 07 
"fee": -0.00000446, 
"abandoned": false 
] } 
1 
"hex": "0200000001al2cb541e92815d3bee2a2cf0celff56b5d9ab87407a39b5ee6q7d81 
d48al26b200000006b483045022100fdb82eb83244c98e3cb7cflfa94be72439ee2abc33a 


9fafe92f0933285e72f5f02204d7dqb0b30979e606dq776a42e0dc3effelbf92dq2dec86f9 
Cb83bd8943e042e8130121030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f4343486 
07368e52644febffeffffff02a08601000000000017a9144f0017ef9291b625bec1d7e 
facc246a37b293682879a2f5blc000000001976a9148ef215e303219e805be7501cfccf76 
0ccdefaf1988ac65031200" 





6 .解码 交易 的 hex 值 

















为 什么 要 研究 交易 的 hex 值 呢 ” 其实 这 个 hex 值 才 是 最 终 发 送 到 比特 币 网 络 里 的 信息 。 我 们 把 它 解码 以 后 ， 可 以 发 现 这 是 一 个 标准 的 比特 币 交易 结构 : 





root@iZ2zeb4wal7uttyf80bcriZ:~# bitcoin-cli decoderawtransaction 0200000001al 
2cb541e92815d3bee2a2cf0celff56b5d9ab87407a39b5ee6d7d81d48al26b200000006b 
483045022100fdb82eb83244c98e3cb7cflfa94be72439ee2abc33a9fafe92f0933285e72 
£5£02204d7db0b30979e606d776a42e0dc3effelbf92d2dec86f9cb83bd8943e042e8130121 
030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e52644febffeffff 
ff02a08601000000000017a9144f0017ef9291b625becld7efacc246a37b293682879a2f5b1 
c000000001976a9148ef215e303219e805be7501cfccf760ccdefaf1988ac65031200 


"txid": "8c67e4d3264696dq222d5a72c70c8806eb3f12b9a02dqlbc80554ab00803be86c0"， 
"hash": "8c67e4d3264696d222d5a72c70c8806eb3f12b9a02d1lbc80554ab00803be86c0", 
Yi 

"vsize": 224, 

"version": 2, 

"locktime": 1180517, 








win"s [ 
{ 
"txid": "6b128ad4817d6deeb5397a4087abd9b556ffel0ccfa2e2bed31528e941b52cal", 
out 32, 
"scriptSsig": { 


"asm": "3045022100fdb82eb83244c98e3cb7cflfa94be72439ee2abc33a9fafe92 
£0933285e72£5£02204d7db0b30979e606d776a42e0dc3effelbf92d2dec86f9cb8 
3bd8943e042e813[ALL] 030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f43 
4348607368e52644febf", 

"hex": "483045022100fdb82eb83244c98e3cb7cf1fa94be72439ee2abc33a9fafe9 
2£0933285e72£5£02204d7db0b30979e606d776a42e0dc3effelbf92d2dec86f9cb 
83bd8943e042e8130121030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434 
348607368e52644febf" 

}, 
"sequence": 4294967294 
} 
J 
out™s I 
{ 
"value": 0.00100000, 
mn": 0, 
"scriptPubKey": { 
asm": "OP HASH160 4f0017ef9291b625becld7efacc246a37b293682 OP_EQUAL", 
a9144f0017ef9291b625becld7efacc246a37b29368287", 
"reqSigs": 1, 
"type": "scripthash", 
"addresses": [ 
"2MzSwUwBc1xuNHwRotwrdFugLvju8VV9uPT™" 
] 


: 








"value": 4.75738010, 
rnn: 1, 
"scriptPubKey": 
"asm": "OP DUP OP HASH160 8ef215e303219e805be7501cfccf760ccdefaf19 
OP_ EQUAIVERIFY OP_CHECKSIG", 
"hex": "76a9148ef215e303219e805be7501cfccf760ccdefaf1l988ac", 
"reqSigs": 1, 
"type": "pubkeyhash", 
"addresses": [ 
"mtYnFgv98bPzx7mdl1VUkyZhWMRgozH4Qsm" 








这 笔 交易 里 包含 交易 的 元 信息 、 输 入 信息 (input) 、 输 出 信息 (output) 等 。 可 以 看 到 在 我 们 前 面 生成 的 地 址 2MzSwUwBc1xuNHwRotwrdFugLvju8VV9uPT 里 ， 有 一 个 0.001 的 UTXO， 可 以 上 


后 的 消费 。 





至 此 ， 在 比特 币 全 节点 下 创建 多 签名 地 址 以 及 对 多 签名 地 址 进行 转账 已 经 完成 。 接 下 来 的 任务 就 是 : 如 何 从 一 个 多 签名 账户 里 消费 比特 


9.2.4” 兄 现 多 签名 交易 











可 




















于 以 


要 想 深入 理解 多 签名 交易 ， 不 仅 要 从 逻辑 上 理解 多 签名 交易 的 流程 ， 而 且 要 解读 交易 中 的 hex 值 。 在 笔者 的 跨 链 开发 过 程 中 ， 经 常 遇 到 一 笔 交易 里 某 些 最 终 的 hex 值 (比如 签名 等 ) 有 问题 ， 不 得 不 逐一 





破解 交易 hex 值 的 结构 。 在 这 里 我 们 演示 消费 一 个 多 签名 账户 的 UTXO， 也 会 讲解 交易 的 hex 值 结构 。 


1. 生 成 新 地 址 














再 生成 一 个 新 地 址 ， 用 于 接收 从 多 签名 账户 转 过 来 的 比特 币 : 





可 


FooteiZz2zeb4wal7uttyf80bcri2:~# bitcoin-cli getnewaddress 
nlMgodk5eJ6QaDMh8BUPBUygAExYNc4VMO 





2. 创 建交 易 











createrawtransaction 接 收 两 个 参数 : input 和 output。 返 回 值 为 交易 的 hex 值 ， 这 时 的 交易 没有 任何 签名 : 





root@iZ2zeb4wal7uttyf80bcri2Z:~# bitcoin-cli createrawtransaction ''' 
[ 
{ 
"txid": "8c67e4d3264696d222d5a72c70c8806eb3f12b9a02dlbc80554ab00803b 
e86c0", 
vout yy DY 


} 


"nlMgodk5eJ6QaDMhn8BUPBUygAExYNc4VMO": 0.00080000 
jr 
0200000001c086be0308b04a5580bcd1029a2bf1lb36e80c8702ca7d522d2964626d3e4678c 
0000000000ffffffff0180380100000000001976a914d9al1d77497c0009446316a05c491c55 
q7ccdd67a88ac00000000 














利用 decoderawtransaction 来 查看 交易 的 信息 : 








root@iZ2zeb4wal7uttyf80bcri2Z:~# bitcoin-cli decoderawtransaction 
0200000001c086be0308b04a5580bcd1029a2bf1lb36e80c8702ca7d522d2964626d3e467 
8c0000000000ffffffff0180380100000000001976a914dq9a1dq77497c0009446316a05c491c 
55d7ccdd67a88ac00000000 


"txid": "688fd635ca944b635e34e94618aef5c5060969495b55ad011192bfbbcdac44b3"， 
"hash": "688f£d635ca944b635e34e94618aef5c5060969495b55ad011192bfbbcdac44b3", 
Vola 857 

"vsize": 85, 

"ersion": 2 

"locktime": 0, 

in [ 


{ 





"8c67e4d3264696d222d5a72c70c8806eb3f12b9a02d1lbc80554ab00803be86c0", 





’ 


"asm": 
mhexn: mm 
] 
"sequence": 4294967295 
} 
], 
wt 
{ 
"value": 0.00080000, 
mn": 0, 
"scriptPubKey": { 
"asm": "OP DUP OP _ HASH160 d9ald77497c0009446316a05c491c55d7ccdd67a 
OP EQUALVERIFY OP CHECKSIG", 
"hex" : "76a914d9a1d77497c0009446316a05c491c55d7ccdd67a88ac", 
"reqSigs": 1, 
"type": "pubkeyhash", 
"addresses": [ 
"nlMgodk5eJ6QaDMhn8BUPBUygAExYNc4VMO" 





可 以 看 到 ， 此 时 的 input 里 没有 任何 签名 ，scriptSig 为 空 。 


3. 获 取 多 签名 账户 的 私 钥 











我 们 在 之 前 生成 了 三 个 新 账户 ， 并 利用 这 三 个 新 账户 生成 了 多 签名 账户 。 这 三 个 新 账户 都 是 由 全 节点 进行 维护 的 ， 可 以 根据 地 址 获取 账户 私 钥 : 











root@iZ2zeb4wal7uttyf80bcri2Z:~# bitcoin-cli dumpprivkey mpFLSDjCcxekrrcdQd62k 
YyUrPHiAGck8mx 

CTo9DZNyvYRRz8f£t115n7caZZ1Mh3qTb7FZaRsmXKVWxMVbdf5ja 

root@i2Z2zeb4wal7uttyf80bcri2Z:~# bitcoin-cli dumpprivkey mxUZ5SQfEcmCHSb8KnsDs 
26byEtSdwbv23 

CToeGZSh5gm2Zteti2fSHqQOhMR27LVsg8ajnRyRxX5nBShwDokU4Y 





我 们 之 前 生成 的 是 一 个 2-of-3 的 多 签名 地 址 ， 也 就 是 说 只 需要 2 个 账户 签名 就 够 了 。 


4 .使 用 私 钥 进行 签名 











这 里 用 到 的 命令 是 signrawtransaction ， 这 个 命令 的 格式 为 : 














signrawtransaction "hexstring" ( [{"txid":"id","vout":n,"scriptPubKey 


"redeemScript":"hex"},http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/...] ["privatekeyl",http://www.hzcourse.com/resc 





hex 就 是 之 前 创建 的 交易 值 。 








我 们 使 用 一 个 私 钥 对 交易 进行 签名 : 











bitcoin-cli signrawtransaction "0200000001c086be0308b04a5580bcd1029a2bflb36e 
80c8702ca7dq522dq2964626dq3e4678c0000000000ffffffff0180380100000000001976a914d 
9a1dq77497c0009446316a05c491c55d7ccdqq67a88ac00000000' 5 
{ 
"txid": "8c67e4d32646969222d5a72c70c8806eb3f12b9a02dlbc80554ab00803be 
86c0"， 
oatns 0 
"scriptPubKey": "a9144f0017ef9291b625becld7efacc246a37b29368287", 
"redeemScript": "522103b91ff254ae3bb3861le4a6c16ab356d6c52ccfd2b58bedf 
0dqa84657dfd9d9afc21039f1475fb37d91ed65765c897acbdc37da3a7abal9f5b8 
ad5ff22a994e835079821030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f43 
4348607368e52644febf53ae" 


"CTO9bZNyvYRRz8ft115n7caZ21Mh3qTb7FZaRsmXKVWxMVbdf5ja" 


i 





签名 完 以 后 查看 该 交易 的 信息 : 





root@iZ2zeb4wal7uttyf80bcriZ:~# bitcoin-cli decoderawtransaction 0200000001c0 
86be0308b04a5580bcd1029a2bf1lb36e80c8702ca7d522d2964626d3e4678c00000000b50 
0483045022100elbdf233e54abbbf22adc4bc70ba531ea35fc72c0240c32f2b7a1647694702 
01022072dc47ddf230e77279a27732blf5cfe8ala8e32063fc8708270fbad3116al57e0 
14c69522103b91ff254ae3bb3861le4a6cl6ab356d6c52ccfd2b58bedf0dda84657dfd9d9afc 
21039f£1475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22a994e8350798210 
30ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e52644febf53aefff 
££ffff£0180380100000000001976a914d9ald77497c0009446316a05c491c55d7ccdd67a88 
ac00000000 


"d8450479e4d5c00603930e3ac24fd6blfe6ddd6a8380d96641776ae9dd5bb634", 
"d8450479e4d5c00603930e3ac24fd6blfe6ddd6a8380d96641776ae9dd5bb634", 
"size": 266, 

"vsize": 266, 

"ersion”: 2; 

"locktime": 0, 

ba As bt 








"txid": "8c67e4d3264696d222d5a72c70c8806eb3f12b9a02d1lbc80554ab00803be86c0", 
"wout™: 0, 
VooriotSig"s f 

"asm": "0 3045022100elbdf233e54abbbf22adc4bc70ba531ea35fc72c0240c32f2 
b7al64769470201022072dc479df230e77279a27732blf5cfe8ala8e32063fc870 
8270fbad3116al57e[ALL] 522103b91ff254ae3bb386le4a6cl6ab356d6c52ccfd 
2b58bedf0dda84657dfd9d9afc21039f1475fb37d91ed65765c897acbdc37da3 
a7Tabal9f5b8ad5ff22a994e835079821030ee8793fa2cb93f0cfd475b990cbaa48a 
28d83bd8f434348607368e52644febf53ae", 

"hex": "00483045022100elbdf233e54abbbf22adc4bc70ba531ea35fc72c0240 
c32f2b7a164769470201022072dc47ddf230e77279a27732blf5cfe8ala8e32063 
fc8708270fbad3116al57e014c69522103b91ff254ae3bb3861le4a6c16ab356d6c 
52ccfd2b58bedf0dda84657dfd9d9afc21039f1475fb37d91ed65765c897acbdc3 


7da3a7abal9f5b8ad5ff22a994e835079821030ee8793fa2cb93f0cfd475b990cba 
a48a28d83bd8£434348607368e52644febf53ae" 
}, 
"sequence": 4294967295 
} 
], 
out™s I 
{ 
"value": 0.00080000, 
mn": 0, 
"scriptPubKey": 
"asm": "OP DUP OP HASH160 d9ald77497c0009446316a05c491c55d7ccdd67a 
OP EQUALVERIFY OP CHECKSIG", 
"hex™: "76a914d9a1d77497c0009446316a05c491c55d7ccdd67a88ac", 
"reqSigs": 1, 
"type": "pubkeyhash", 
"addresses": [ 
"nlMgodk5eJ6QaDMh8BUPBUygAExYNc4VMO" 

















可 以 看 到 ， 在 input 里 已 经 有 签名 信息 了 。 我 们 再 用 另 一 个 私 钥 对 交易 进行 签名 : 

















bitcoin-cli signrawtransaction "0200000001c086be0308b04a5580bcd1029a2bflb36e 
80c8702ca7d52292964626d3e4678c00000000b500483045022100elbdf233e54abbbf22adc 
4bc70ba531ea35fc72c0240c32f2b7a164769470201022072dc47ddf230e77279a27732b1f5 
cfe8ala8e32063fc8708270fbad3116al57e014c69522103b91ff254ae3bb386le4a6c16 
ab356d6c52ccfd2b58bedf0dda84657dfd9d9afc21039f1475fb37d91ed65765c897acbdc37 
da3a7abal9f5b8ad5ff22a994e835079821030ee8793fa2cb93f0cfd475b990cbaa48a28d83 
bd8f434348607368e52644febf53aeffffffff0180380100000000001976a914d9a1ld77497c 
0009446316a05c491c55d7ccdd67a88ac00000000" ?7 
[ 
{ 
"txid": "8c67e4d3264696dq222d5a72c70c8806eb3f12b9a02dqlbc80554ab00803be 
86c0"， 
"vout": 0, 
"scriptPubKey": "a9144f0017ef9291b625becld7efacc246a37b29368287", 
"redeemScript": "522103b91ff254ae3bb3861le4a6c16ab356d6c52ccfd2b58bedf 
0dqa84657dfd9d9afc21039f1475fb37d91ed65765c897acbdc37da3a7abal9f5b8 
ad5ff22a994e835079821030ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f43 
4348607368e52644febf53ae" 


"cToeG2ZSh5gmZzteti2fSHqQhMR27LVsg8ajnRyRxX5nBShwDokU4Y" 


J 


{ 

"hex": "0200000001c086be0308b04a5580bcd1029a2bflb36e80c8702ca7d522d2964626d 
3e4678c00000000fdfd0000483045022100elbdf233e54abbbf22adc4bc70ba531ea35 
fc72c0240c32f2b7a164769470201022072dc47ddf230e77279a27732blf5cfe8ala8e320 
63fc8708270fbad3116a1l57e0147304402204c5eebfbaba5c8bb899b737£f50919c31cd27 
650e96c0fb6ad7d22d02bc126cb5022014d7a7a4046372b2772fe37b8a8b82104828a899d 
bcfc140cb9b52ba9b04e460014c69522103b91ff254ae3bb3861le4a6c16ab356d6c52c 
cfd2b58bedf0dda84657dfd9d9afc21039£f1475fb37d91ed65765c897acbdc37da3a7ab 
al9f5b8ad5ff22a994e835079821030ee8793fa2cb93f0cfd475b990cbaa48a28dq83bd8 
£434348607368e52644febf53aeffffffff0180380100000000001976a914d9ald77497c0 
009446316a05c491c55d7ccdd67a88ac00000000", 

"complete": true 

} 


























使 用 两 个 私 钥 签 名 过 后 ， 状 态 complete 为 true， 说 明 该 交易 已 经 满足 多 签名 消费 的 条 件 ， 可 以 进行 广播 了 。 


5. 广 播 该 交易 














使 用 sendrawtransaction 广 播 该 交易 : 





root@iZ2zeb4wal7uttyf80bcriZ:~# bitcoin-cli sendrawtransaction 0200000001c086 
be0308b04a5580bcd1029a2bflb36e80c8702ca7d52292964626d3e4678c00000000fdfqd0 
000483045022100elbdf233e54abbbf22adc4bc70ba531ea35fc72c0240c32f2b7a16476 
9470201022072dc47ddf230e77279a27732blf5cfe8ala8e32063fc8708270fbad3116a157 
e0147304402204c5eebfbaba5c8bb899b737£f50919c31cd27650e96c0fb6ad7d22d02bc126c 
b5022014d7a7a4046372b2772fe37b8a8b82104828a89ddbcfc140cb9b52ba9b04e4600 
14c69522103b91ff254ae3bb3861e4a6c16ab356q6c52ccfd2b58bedf0dqa84657dfdq9dq9afc 
21039f1475fb37dq91led65765c897acbdc37dqa3a7abal9f5b8ad5ff22a994e8350798210 
30ee8793fa2cb93f0cfd475b990cbaa48a28d83bd8f434348607368e52644febf53aefff 
fffff0180380100000000001976a914dq9a1d77497c0009446316a05c491c55d7ccdd67a88 
ac00000000 

04839f5905aa363d18aff5b559892bb54ddf4e0c7066a7072b942d71f2fa9470 





交易 完成 ， 此 时 可 以 去 区 块 链 浏览 器 查看 交易 相关 的 信息 了 。 





6 .交易 的 hex 值 结构 变化 


在 刚刚 创建 交易 没有 任何 签名 时 ， 交 易 的 结构 为 : 





<Part1> 

0800000001c086be0308b04a5580bcdl029a2bflb36e80c8702ca7d522d2964626d3e467 
8c00000000 

</Part1> 

00 

<output> 

££fffffff£0180380100000000001976a914d9ald77497c0009446316a05c491c55d7ccdd67a88 
ac00000000 

</output> 





在 第 一 个 私 钥 签名 以 后 ， 结 构 变 成 : 





<Part1> 

0200000001c086be0308b04a5580bcd1029a2bflb36e80c8702ca7d522d2964626d3e467 
8c00000000 

</Part1> 

b5 

<0> 

0048 

</0> 

<sigl> 

3045022100elbdf233e54abbbf22adc4bc70ba531ea35fc72c0240c32f2b7a164769470201022 
072dc47ddf230e77279a27732blf5cfe8ala8e32063fc8708270fbad3116a1l57e01 

</sigl> 

4c69 

<redeemScript> 

522103b91ff254ae3bb3861e4a6c16ab356d6c52ccfd2b58beqf0ddqa84657dfd9d9afc21039f1 
475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22a994e835079821030ee8793fa2 
Cb93f0cfd475b990cbaa48a28d83bd8f434348607368e52644febf53ae 

</redeemScript> 

<output> 


££ffffff£0180380100000000001976a914d9ald77497c0009446316a05c491c55d7ccdd67a88 
ac00000000 
</output> 





第 二 个 私 钥 签 名 以 后 ， 结 构 变 成 : 





<Part1> 

0800000001c086be0308b04a5580bcdl1029a2bflb36e80c8702ca7d522d2964626d3e467 
8c00000000 

</part1> 

fdfd00 

<0> 

0048 

</0> 

<sigl> 

3045022100elbdf233e54abbbf22adc4bc70ba531ea35fc72c0240c32f2b7a1l64769470201022 
072dc47ddf230e77279a27732blf5cfe8ala8e32063fc8708270fbad3116a1l57e01 

</sigl> 

47 

<sig2> 

304402204c5eebfbaba5c8bb899b737£50919c31cd27650e96c0fb6ad7d22d02bc126cb502201 
4d7a7a4046372b2772fe37b8a8b82104828a89qqbcfc140cb9b52ba9b04e46001 

</sig2> 

4c69 

<redeemScript> 

522103b91ff254ae3bb386le4a6cl6ab356d6c52ccfd2b58bedf0dda84657dfd9d9afc21039f1 
475fb37d91ed65765c897acbdc37da3a7abal9f5b8ad5ff22a994e835079821030ee8793fa2 
cb93f0cfd475b990cbaa48a28dq83bd8f434348607368e52644febf53ae 

</redeemScript> 

<output> 

ffffffff0180380100000000001976a914dq9ald77497c0009446316a05c491c55d7ccdq67a88 
ac00000000 

</output> 





返回 值 为 txid。 














这 就 是 比特 币 多 签名 交易 的 基本 原理 。 在 Asch 的 跨 链 实现 里 ， 就 是 利用 了 这 个 机 制 来 完成 资产 的 双向 锚 定 与 流通 。 














9.3 ”Asch 的 跨 链 实现 








在 多 签名 交易 的 基础 上 ，Asch 实 现 了 一 种 通过 多 签名 联盟 来 实现 的 双向 资产 锚 定 方案 ， 这 里 面 最 重要 的 角色 是 跨 链 网 关 。 如 图 9-3 所 示 ， 跨 链 网 关 是 一 个 有 多 个 节点 共同 维护 的 多 签名 地 址 集合 。 为 了 





























完成 。 资 产 从 原来 的 3 














反 。 参 见 图 9-3。 




















选举 出 合适 的 网 关节 点 ，Asch 开 发 了 一 个 提案 系统 ， 用 于 用 户 对 网 关节 点 进行 投票 。 网 关节 点 各 自 同 时 维护 着 其 他 主 链 的 全 节点 和 Asch 的 全 节点 。 跨 链 资产 到 Asch 的 充值 、 提 现 等 工作 都 是 由 这 些 节点 来 
E 链 进入 跨 链 网 关 以 后 ， 会 在 原来 的 主 链 上 锁定 资产 ， 同 时 Asch 会 解锁 一 笔 对 应 的 资产 ， 用 于 Asch 内 部 使 用 。 





























户 可 以 随时 从 Asch 提 现 到 原来 的 主 链 ， 这 个 过 程 和 充值 的 过 程 完全 相 























在 Asch 的 跨 链 资产 流通 的 过 程 中 ， 主 要 有 四 个 过 程 : 网 关 提 案 的 发 起 与 投票 ， 跨 链 账户 的 开通 ， 对 跨 链 网 关 的 充值 与 提现 。 接 下 来 我 们 会 深入 探讨 这 四 个 部 分 的 实现 与 流程 。 
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图 9-3 Asch 的 跨 链 实现 


9.3.1 “网关 提案 的 发 起 与 投票 








区 块 链 和 公司 不 同 ， 它 的 运转 和 治理 基于 社区 成 员 的 深度 参与 。 为 此 Asch 引 入 了 一 个 提案 系统 ， 这 与 DPos 机 制 下 选举 见证 人 的 方案 类 似 。 社 区 成 员 可 以 发 起 提案 并 引导 大 家 来 投票 。 如 果 投 票 通过 ， 














则 这 项 提案 就 会 进入 实施 阶段 ， 如 图 9-4 所 示 。 


发 起 新 提案 


全 体 社区 不 通 


过 
和 习 ， 社区 决议 过 期 或 重新 发 起 


通过 


提案 成 功 





图 9-4” 跨 链 网 关 的 上 线 流程 





为 了 支持 跨 链 网 关 ，Asch 设 计 了 四 种 提案 类 型 ， 分 别 对 应 新 增 网 关 、 网 关 初 始 化 、 更 换 网 关 成 员 以 及 注销 网 关 ， 代 码 如 下 : 


const VALID TOPICS = [ 
"gateway_Tegister' 
'gateway init', 
'gateway_update member', 
'gateway_revoke', 


下 面 介绍 网 关 提案 实施 流程 。 





1. 发 起 “新 增 网 关 ” 提 案 





对 于 跨 链 网 关 来 说， 首先 由 社 














区 成 员 在 Asch 网 页 客户 端 (首页 一 提案 ) 发 起 “新 增 网 关 ” 提 案 ， 如 图 9-5 所 示 。 














Bitcoin Gateway Proposal 
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2018-07-08 





BitcoinGateway 





图 9-5 在 客户 端 发 起 “新 增 网 关 ” 提 案 














在 图 9-5 的 注册 网 关 流程 中 ， 提 案 发 起 人 需要 填写 “提案 类 型 。 “成员 数量 ”以 及 “公投 周期 ” 《用 于 给 用 户 评估 项 目 并 投票 ) 、“ 网 关 名 字 ” “默认 币 种 ”等 信息 。 发 起 提案 会 调用 主 链 的 proposal 
合约 。 该 合约 代码 如 下 : 





async propose (title, desc, topic, content, endHeight) { 

// 条 件 验 证 

if (!/^[A-2a-z0-9 \-+!@$% ]{10,100}$/.test (title)) return 'Invalid 
proposal title' 

if (desc.length > 4096) return 'Invalid proposal description' 

if (VALID TOPICS.indexOf (topic) === -1) return 'Invalid proposal topic' 

if (!Number.isInteger (endHeight) 11 endHeight < this.block.height + 8640) 
return 'Invalid proposal finish date' 


// 根据 提案 类 型 调用 不 同 的 方法 
if (topic =—= 'gateway register') { 
await validateGatewayRegister (content, this) 
} else if (topic =—= 'gateway init') { 
await validateGatewayInit (content, this) 
} else if (topic ==—= 'gateway update member') { 
await validateGatewayUpdateMember (content, this) 
} else if (topic =—= 'gateway revoke') { 
await validateGatewayContent (content, this) 
} 


// 创建 提案 的 数据 库 记 录 
app.sdb.create('Proposal', { 
tid: this.trs.id, 
timestamp: this.trs.timestamp, 
title, 
desc, 
topic, 
content: JSON.stringify (content), 
activated: 0, 
height: this.block.height, 
endHeight, 
senderId: this.sender.address, 
}) 


return null 



































合约 会 检测 用 户 想 要 发 起 的 提案 类 型 ， 然 后 去 调用 对 应 的 方法 实现 。 对 于 新 增 网 关 这 个 类 型 的 提案 ， 调 用 的 方法 如 下 : 

















async function doGatewayRegister (params, context) 1{ 
const name = params.name 
app.sdb.1lock( “gateway@$ {name} `) 
Const exists = await app.sdb.exists('Gateway', { name }) 
if (exists) throw new Error('Gateway already exists') 


app.sdb.create('Gateway', { 
name, 
desc: params.desc, 
updateInterval: params.updateInterval, 
minimumMembers: params.minimumMembers, 
lastUpdateHeight: context.block.height, 
revoked: 0, 
version: 1, 
activated: 0, 
createTime: context.trs.timestamp, 

和 

app.sdqb.create ('GatewayCurrency'，1{ 
gateway: name, 
Symbol: params.currency.symbol, 
precision: params.currency.precision, 
desc: params.currency.desc, 
revoked: 0, 

hy 





创建 的 数据 都 记录 在 SQLite3 里 ， 读 者 可 以 在 相应 的 数据 表 中 查 到 相关 提案 及 网 关 信 息 。 
2. 社 区 讨论 及 投票 


一 个 提案 发 起 以 后 ， 需 要 经 过 社区 的 讨论 。 在 发 起 提案 时 设 定 的 时 间 周 期 内 ，Asch 的 见证 人 会 对 该 提案 进行 投票 。 如 果 一 项 提案 可 以 收集 到 68 位 见证 人 以 上 的 投票 ， 那 么 就 通过 该 提案 ， 进 入 实施 阶 
段 。 


Oi 


68 这 个 数字 是 怎么 来 的 呢 ? 阿 希 采 用 的 是 DPoS+PBFT (实用 拜占庭 容错 ) 共识 机 制 ， 在 这 种 机 制 下 ， 总 节点 数 (n) 和 恶意 节点 (m) 的 关系 只 要 满足 n 宇 3m+1 就 可 以 达成 共识 。 阿 希 目 前 的 产 块 节点 数 
是 101， 因 此 ms (101 -1) /3， 也 就 是 恶意 节点 只 要 不 超过 33 个 ， 最 后 就 可 以 达成 共识 。 反 过 来 讲 ， 只 要 诚实 节点 大 于 101 - 33=68 人 个， 那么 此 轮 产 块 就 可 以 达成 共识 。 








投票 合约 相关 代码 如 下 : 





async vote (Pid) { 

if (!app.isCurrentBookkeeper (this.sender.address)) return 'Permission 
denied' 

const proposal = await app.sdb.findone('Proposal', { condition: { tid: 
pid } }) // 寻找 提案 

if (!proposal) return 'Proposal not found' 

if (this.block.height - proposal.height > 8640 * 30) return 'Proposal 
expired' 

Const exists = await app.sdb.exists('ProposalVote', { voter: this.sender. 
address, pid }) 

if (exists) return 'Already voted' 

// 创建 投票 

app.sdb.create('ProposalVote', { 
tids thisv tra id 
pid, 
voter: this.sender.address, 

}) 


return null 





投票 可 以 在 Asch 客 户 端 进行 ， 投 票 操作 产生 的 数据 也 会 存储 到 数据 库 。 


3. 竞 选 网 关 候选 人 














如 果 一 切 顺 利 ， 在 一 个 “新 增 网 关 ” 的 提案 发 起 通过 以 后 ， 接 下 来 就 需要 进行 发 起 “网 关 初 始 化 ”的 提案 了 。 不 过 在 网 关 初 始 化 之 前 ， 需 要 社区 成 员 进行 “网 关 成 员 ” 的 注册 。 网 关 成 员 就 是 维护 跨 链 
网 关 的 成 员 ， 除 了 维护 Asch 的 全 节点 以 外 还 需要 维护 其 他 跨 链 资产 的 全 节点 。 网 关 成 员 自由 竞选 ， 需 要 在 社区 里 寻求 支持 。 























注册 网 关 成 员 的 合约 如 下 : 





async registerMember (gateway, publicKey, desc) { 
// 各 种 验证 条 件 


if (!gateway) return 'Invalid gateway name 


const senderId = this.sender.address 
app.sdb.lock (‘basic.account@$ {this.sender.address}.) 
const sender = this.sender 
if (!sender.name) return 'Account have not a name' 
if (sender.role) return 'Account already have a role' 
if (lawait app.sdb.exists('Gateway', { name: gateway })) return 'Gateway 
not found' 
Const exists = await app.sdb.exists('GatewayMember', { address: senderId }) 
if (exists) return 'Account already is a gateway member' 
// 一 个 账户 只 能 拥有 一 个 角色 ， 这 里 会 创建 网 关 验 证 人 的 角 
sender.role = app.AccountRole.GATEWAY VALIDATOR 
app.sdb.update('Account', { role: app.AccountRole .GATEWAY VALIDATOR }, { 
address: this.sender.address }) I 
app.sdb.create ('GatewayMember', { 
address: this.sender.address, 
gateway, 
outPublicKey: publickey, 
desc, 
elected: 0, 
}) 


return null 


注册 网 关 候选 人 的 操作 目前 无 法 在 客户 端 完成 ， 请 参考 相关 文档 [1]。 该 操作 会 消耗 100XAS。 


4 .发 起 “网 关 初始 化 ”提案 


























在 已 经 拥有 足够 网 关 成 员 的 情况 下 ， 社 区 成 员 可 以 发 起 “网 关 初 始 化 ”的 提案 。 进 入 Asch 网 页 客户 端 以 后 ， 在 提案 (首页 一 提案 ) 界面 ， 提 案 发 起 人 可 以 任意 选择 自己 认为 合适 的 网 关 候选 人 。 提 案 示 
例 参见 图 9-6。 














之 提案 详情 


Init bitcoin gateway validators 








网 关 初 始 化 





2018/07/03 15:14:31 | 至 | 2018/7/09 15:08:31 





网 关 名 字 bitcoin 


我 提议 AHxRhrtSZYfGMYXq8LBRC2jwvapSG3YfH3 , A6WrQQBCLgcWvAhEJw4M2csQvoqLDGBTE2 , A52Lhtz1Yd77ut9 
vcR4ouJiWiZzmGLUmYD1 等 3 人 成 为 网 关 成 员 





图 9-6 发 起 新 提案 














网 关 初 始 化 会 调用 proposaljs 里 的 doGatewaylnit 合 约 ， 网 关 初 始 化 的 合约 代码 如 下 : 





async function doGatewayInit (Params) { 
for (const m of params.members) { 
const dbItem = await app.sdb.get('GatewayMember', m) 
dbItem.elected = 1 
} 
const gateway = await app.sdb.get ('Gateway', params.gateway) 
gateway.activated = 1 
} 





5. 社 区 讨论 及 投票 








这 个 步骤 和 “新 增 网 关 ” 的 提案 类 似 ， 不 同 的 是 社区 成 员 对 认可 哪个 提案 (不 同 提案 可 能 包含 不 同 的 网 关 候选 人 ) 有 了 更 多 的 选择 。 


6. 网 关上 线 


























如 果 革 个 “网 关 初始 化 ”的 提案 通过 ， 那 么 该 提案 所 涉及 的 网 关 候选 人 会 进行 网 关上 线 的 工作 。 主 要 工作 为 配置 一 个 其 他 跨 链 资产 的 全 节点 (比如 是 Bitcoin 或 者 BitcoinCash 等 ， 就 需要 配置 
bitcoind) ， 同 时 在 自己 维护 的 Asch 节 点 的 configjson 中 ， 添 加 如 下 的 配置 (示例 ) : 





"gateway": { 

"name": "bitcoincash", 

"rpc":; {"username": "Asch", "password":"Asch123456", "host": 
"T1921686,1 .190" "port"s 19332}; 

"secret": "cabbage outdoor extend memory ketchup powder turtle trial 
interest ticket anchor season", 

"OutSecret": "CR41t5PH83okfAGzxqwCdWN17SXXoUS2rJjx5D9iSAcJ1SwrwvSWdS"， 

"sendWithdrawal": true 

















Asch 节 点 在 启动 时 会 检查 是 否 配 置 为 跨 链 网 关节 点 ， 会 应 用 相应 的 配置 和 跨 链 资 产 全 节点 进行 交互 。 

















[由 请 参考 https://github.com/ AschPlatform/asch-docs/blob/master/http_api/zh-cn.md。 


9.3.2 ” 跨 链 账户 的 开通 

















在 跨 链 网 关上 线 以 后 ， 所 有 的 用 户 都 可 以 在 Asch 的 客户 端 开通 跨 链 账户 了 。 每 一 个 Asch 用 户 都 有 一 个 唯一 的 跨 链 账 户 ， 这 个 账户 是 根据 跨 链 网 关 所 有 节点 的 公 钥 以 及 用 户 自己 的 公 钥 一 起 生成 的 。 











1. 开 通 账户 














开通 账户 调用 的 是 chain.js 里 的 openAccount 合 约 ， 代 码 如 下 : 





async openAccount (gateway) { 
if (!gateway) return 'Invalid gateway name' 


app.sdb.1lock (‘gateway.openAccount@$ {this.sender.address}.) 

Const exists = await app.sdb.exists('GatewayAccount', { address: this. 
sender.address }) 

if (exists) return 'Account already opened' 

const validators = await app.sdb.findAll ('GatewayMember', { condition: { 
gateway, elected: 1 } }) 


if (!validators || !validators.length) return 'Gateway Validators not 


found' 


Const gw = await app.sdb.findone('Gateway', 
if (!gw) return "Gateway not found' 


if (!gw.activated) return 'Gateway not activated' 
if (gw.revoked) return "Gateway already revoked' 


// 获取 网 关 验 证 人 的 公 钥 


{ condition: 


const outPublicKeys = validators.map (V => v.outPublicKey) 


// 设 定 解锁 门槛 ，m-of-n 里 的 


m 


const unlockNumber = Math.floor (outPublicKeys.length / 2) + 1 
outPublicKeys .push (“02${this.trs.senderPublicKey}.) 


// 创建 唯一 的 多 签名 账户 


const account = app.gateway.createMultisigAddress (gateway, unlockNumber, 


outPublicKeys) 


const seq = Number (app.autoID.increment ('gate account seq')) 
app.sdb.create('GatewayAccount', { 
address: this.sender.address, 


gateway, 


outAddress: account.address, 
attachment: account.accountExtrsInfo, 


Seq, 
version: gw.version, 


createTime: this.trs.timestamp, 


过 


return null 


{ name: gateway } 


}) 








所 有 的 跨 链 账户 都 会 写 入 GatewayAccount 数 据 表 。 


2. 导 入 网 关节 点 














创建 完 跨 链 账 户 以 后 ， 如 何 感 知 该 账户 的 充值 和 提现 呢 ? 前 面 说 过 ， 每 个 网 关节 点 都 维护 了 一 个 跨 链 资产 的 全 节点 。 以 比特 币 为 例 ， 每 个 比特 币 全 节点 也 都 是 比特 币 的 钱包 。 跨 链 账 户 创建 以 后 ， 
就 会 以 watchonly 的 模式 导入 到 全 节点 ， 用 于 监听 该 地 址 的 所 有 交易 。 











导入 账户 的 步骤 在 Asch-core 仓 库 的 src/core/gateway.js 里 可 以 找到 ， 代 码 如 下 : 

















// 查找 账户 ， 导 入 节点 
async _importAccounts () { 
Const GATEWAY = this.name 


Const key = { gateway: GATEWAY, type: GatewayLogType.IMPORT ADDRESS } 
let lastImportAddressLog = this. sdb.get('GatewayLog', key) 


library.logger.debug('find last import address log', lastImportAddressLog) 


let lastSeq = 0 
if (lastImportAddressLog) 


lastSeq = lastImportAddressLog.seq 


} else { 


{ 


const value = { gateway: GATEWAY, type: GatewayLogType.IMPORT ADDRESS, 


seq: 0 } 


lastImportAddressLog = this. sdb.create('GatewayLog', value) 


} 
// query( model, condition, fields, limit, offset, sort, join ) 
const gatewayAccounts = await this. sdb.find( 


'GatewayAccount', 
{ gateway: GATEWAY, seq: 
100, 

) { seq: 1 }, 


{ $gt: lastSeq } }, 


library.logger.debug('find gateway account', gatewayAccounts) 
const len = gatewayAccounts.length 


if (len > 0) { 


for (const a of gatewayAccounts) 
await this. importAddress (a.outAddress) 


} 


app.sdb.update ('GatewayLog', 


key) 


this._sdb.saveLocalChanges () 


{ 


{ seq: gatewayAccounts[len - 1] .seq }, 











跨 链 网 关 账 户 是 用 户 使 用 跨 链 资产 的 基础 ， 开 通 跨 链 网 关 的 合约 编号 为 400， 手 续费 是 100 XAS。 




















9.3.3 ”对 跨 链 网 关 的 充值 与 提现 





资产 从 其 他 公 链 转移 到 Asch 的 过 程 称 为 “充值 ”， 而 反方 向 则 称 为 “提现 ”。 充 值 和 提现 的 过 程 都 由 Asch 上 的 合约 来 完成 。 











假如 比特 币 跨 链 系 统 已 经 上 线 ， 






































Asch 会 一 直 监 听 充值 到 跨 链 账户 的 交易 ， 检 测 到 交易 后 则 会 调 





户 想 要 把 自己 的 比特 币 转 入 到 
交易 ， 然 后 在 该 用 户 的 Asch 链 的 地 址 上 生成 一 笔 新 的 等 值 比特 币 资产 。 这 笔 资产 就 可 以 在 Asch 上 流转 并 且 用 在 各 个 DApp 里 了 。 














Ea 








Asch 上 使 


























， 那 么 他 只 


要 把 








己 的 比特 币 转 入 跨 链 网 关 的 地 址 并 等 待 比特 币 网 络 的 确认 。 在 比特 币 网 络 确认 以 后 ，Asch 会 检测 到 这 笔 























合约 gateway.deposit 来 完成 充值 交易 。 我 们 来 看 一 下 充值 部 分 代码 的 主要 逻辑 : 











async po RY address, currency, amount, oid) { 
// 获 


取 网 关 验 证 人 


const validator = await app.sdb.findOone('GatewayMember', { 


condition: { 


address: this.sender.address, 


}, 
向 


if (!validator || !validator.elected || validator.gateway !== gateway) 
return 'Permission denied' 


const signerKey = “gateway.deposit@${[this.sender.address, currency, 


oid] ,join(":")y" 
app.sdb.1lock (signerKey) 
// 获取 网 关 账 号 


const gatewayAccount = await app.sdb.findOone('GatewayAccount', { 


condition: { outAddress: 


address 


‘ 


}) 


if (!gatewayAccount) return 'Gateway account not exist' 


Const gw = await app.sdb.findone('Gateway', 


gatewayAccount .gateway } 


if (!gw) return "Gateway not found' 


}) 


if (gw.revoked) return 'Gateway already revoked' 


if (await app.sdb.exists('GatewayDepositSigner', 


return 'Already submitted' 
app.sdb.create ('GatewayDepositSigner', 


const dipositKey = { oid } 


{ condition: { name: 


{ key: signerKey }) 


let deposit = await app.sdb.load('GatewayDeposit', dipositKey) 


if (!deposit) { 


deposit = app.sdb.create('GatewayDeposit', { 


tlds this.trssid, 


timestamp: this.trs.timestamp, 


gateway, 
currency, 


{ key: signerKey })) 


amounty 

address, 

oid, 
confirmations: 1, 
processed: 0, 


} else { 
deposit.confirmations += 1 
const count = await app.sdb.count ('GatewayMember', { gateway, elected: 1 }) 
if (deposit.confirmations > count / 2 && !deposit.processed) { 
deposit.processed = 1 
app.balances.increase (gatewayAccount .address, currency, amount) 


} 
app.sdb.update ('GatewayDeposit', deposit, dipositKey) 
i 
return null 
}, 





上 面 的 代码 展示 了 网 关节 点 在 检测 到 充值 交易 以 后 的 处 理 情况 。 首 先 验 证 网 关 的 合法 性 (是 否 存在 、 是 否 有 网 关 成 员 等 ) ， 验 证 通过 后 会 根据 情况 新 建 一 笔 Asch 链 上 的 跨 链 交易 或 者 增加 一 次 确认 。 最 
终 修改 账户 的 跨 链 资产 余额 。 


9.3.4 ”对 跨 链 网 关 的 提现 


如 果 用 户 想 把 自己 在 Asch 上 的 跨 链 资产 转移 回 原来 的 主 链 ， 这 个 时 候 就 需要 在 Asch 网 页 客户 端 上 发 起 一 笔 “ 提 现 ”的 操作 (首页 一 资产 一 跨 链 资产 一 提现 ) 。 提 现 的 过 程 主要 有 用 户 发 起 交易 、 跨 链 网 
关节 点 对 交易 进行 签名 以 及 广播 等 。 和 9.2.4 节 里 兑现 多 签名 交易 的 步骤 比较 类 似 。 





图 9-7 展 示 了 从 Asch 上 提取 比特 币 的 过 程 ， 手 续费 可 以 自己 填写 。 








提现 "为 道 免 造成 财产 损失 ， 请 务必 确认 您 的 提现 地 址 ， 本 操作 无 法 撤销 


接受 者 
mme7SuKvrzRonHAZQRgkUtrfEYvrSzEbdb 


金额 ， 要 注意 手续 费 扣 除 问 题 
0.19| 





图 9-7 用 户 发 起 提现 操作 


用 户 发 起 的 提现 操作 使 用 合约 为 403 号 withdrawal， 代 码 如 下 : 





async withdrawal (address, gateway, currency, amount, fee) { 
if (!gateway) return 'Invalid gateway name' 
if (!currency) return 'Invalid currency’' 
app.validate('amount', fee) 
app.validate ('amount', amount) 


const balance = app.balances.get (this.sender.address, currency) 
if (balance.lt(amount)) return 'Insufficient balance' 


const outAmount = app.util .bignumber (amount) .sub (fee) 
if (outAmount.lte(0)) return 'Invalid amount' 


if (!app.gateway.isValidAddress (gateway, address)) return 'Invalid 
withdrawal address' 


app.balances.decrease (this.sender.address, currency, amount) 
const seq = Number (app.autoID.increment ('gate withdrawal seq')) 


app.sdb.create ('GatewayWithdrawal', { 
tid: this.trs.id 
timestamp: this.trs.timestamp, 
Seq, 
gateway, 
Currency, 
amount: outAmount.toString(), 
senderId: this.sender.address, 
recipientId: address, 


fee, 

signs: 0, 

ready: 0, 
outTransaction: '', 
pis LL 


}) 


return null 


] 








这 会 在 gateway_ withdrawals 表 里 新 增 一 笔 交 易 。 同 时 Asch-core/src/gateway 里 的 程序 会 轮 询 数据 库 ， 查 看 gateway_withdrawals 的 值 并 和 gateway logs 里 处 理 的 序列 进行 比较 ， 如 果 发 现 有 新 的 提 
现 操 作 ， 则 进行 处 理 ， 代 码 如 下 : 





async processWithdrawals() { 
Const GATEWAY = this.name 
Const PAGE SIZE = 25 
const validators = await this. sdb.findAll( 
'GatewayMember', 他 
{ 


condition: { 
gateway: GATEWAY, 
elected: 1, 
}, 
}, 
) 
if (!validators || !validators.length) { 
library.logger.error('Cannot find validators') 
return 


} 
library.logger.debug ('Found gateway validators', validators) 





const withdrawalLogKey = { gateway: GATEWAY, type: GatewayLogType. 
WITHDRAWAL } 

let lastWithdrawalLog = await this. sdb.load('GatewayLog', 
withdrawalLogKey) 加 

1ibrary.1ogger.debug ('fim log', 


lastWithdrawalLog) 
lastWithdrawalLog = lastWithdrawalLog 
11 this._sdb.create('GatewayLog', { gateway: GATEWAY, type: 
GatewayLogType .WITHDRAWAL, seq: 0 }) 
const lastSeq = lastWithdrawalLog.seq 


const withdrawals = await this. sdb.find('GatewayWithdrawal', { gateway: 


GATEWAY, seq: { $gt: lastSeq  }, PAGE SIZE) 
library.logger.debug('Found gateway withdrawal transactions', 
withdrawals) 
if (!withdrawals || !withdrawals.length) { 
return 


const outPub1licKeys = validators.map (V => v.outPublicKey) .Sort ((1，L) => 
1 工 一 了 ) 

const unlockNumber 

const multiAccount 
outPublicKeys) 

library.logger.debug('gateway validators cold account', multiAccount) 


Math.floor (outPublicKeys.length / 2) + 1 
this. getUtil() .createMultisigAccount (unlockNumber, 


const onError = (err) => { 
library.logger.error('Process gateway withdrawal error, will retry 
later', err) 


} 


this. spentTids = await this. getSpentTids() 
for (const w of withdrawals) { 
if (w.ready) continue 


try { 
// 处 理 提现 
const fn = this. processWithdrawal .bind (this, w.tid, multiAccount) 
await utils.retryAsync (fn, 3, 10 * 1000, onError) 
library.logger.info('Gateway withdrawal transaction processed', w.tid) 
} catch (e) { 
library.logger.warn('Failed to process gateway withdrawal 
transaction', { error: e, transaction: w }) 


} 


app.sdb.update ('GatewayLog', { seq: withdrawals[withdrawals.length - 
1] .seq }, withdrawalLogKey) 
this. sqb.saveLocalChanges () 
} 


























在 各 种 验证 条 件 都 通过 以 后 ，processWithdrawals 会 调用 processWithdrawal 对 提现 交易 进行 处 理 。 其 基本 逻辑 是 : 跨 链 网 关节 点 如 果 发 现 一 笔 新 的 提现 交易 ， 则 会 使 用 createNewTransaction 创 建 
一 笔 新 的 交易 并 签名 。 如 果 节 点 发 现 交 易 已 经 被 签名 过 一 次 的 话 ， 则 会 直接 在 原来 交易 的 基础 上 进行 签名 。 代 码 如 下 : 


























async processWithdrawal (wid, multiAccount) { 
let contractParams = null 
const w = await this. sdb.load('GatewayWithdrawal', wid) 
const account = { 2 
privateKey: this. outSecret, 
} 
if (!w.outTransaction) { 
const output = [{ address: w.recipientId，value: Number (w.amount) }] 
library.logger.debug('gateway spent tids', this. spentTids) 
Const ot = await this. createNewTransaction( 
multiAccount, 
output, 
this. spentTids, 
Number (w. fee), 
) 
this. spentTids = 
this. spentTids.concat (this. getUtil() .getSpentTidsFromRawTransaction 
(ot .Exhex) ) 
library.logger.debug('create withdrawal out transaction', ot) 


const inputAccountInfo = await this. getGatewayAccountByOutAddress (ot. 
input, multiAccount) 
library.logger.debug('input account info', inputAccountInfo) 


const ots = await this. signTransaction (ot, account, inputAccountInfo) 


library.logger.debug('sign withdrawal out transaction', ots) 


// gateway.submitWithdrawalTransaction 
contractParams = { 
type: 404, 
secret: this. secret, 
fee: 10000000， 
args: [w.tid, JSON.stringify(ot), JSON.stringify(ots)], 
i 
else { 
Const ot = JSON.parse(w.outTransaction) 
const inputAccountInfo = await this. getGatewayAccountByOutAddress (ot. 
input, multiAccount) 
const ots = await this. signTransaction (ot, account, inputAccountInfo) 
// gateway.submitWithdrawalSignature 
contractParams = { 
type: 405, 
secret: global.Config.gateway.secret, 
fee: 10000000, 
args: [w.tid, JSON.stringify(ots)], 
} 


await PIFY (modules.transactions.addTransactionUnsigned) (contractParams) 


} 























等 有 足够 多 的 跨 链 网 关节 点 进行 签名 以 后 ，sendWithdrawal 会 把 这 些 签名 按照 合适 的 顺序 拼装 起 来 ， 封 装 成 一 笔 完整 的 交易 并 利用 全 节点 广播 到 对 应 的 主 链 网 络 里 ， 代 码 如 下 : 














async _sendwithdrawal (outTransaction, outTransactionSignatures, 
multiAccount) { 
try { 
const ot = outTransaction 
const ots = outTransactionSignatures 
const inputAccountInfo = await this. getGatewayAccountByOutAddress (ot. 
input, multiAccount) 
library.logger.debug ('before build transaction') 
Const finalTransaction = this. getUtil() .buildTransaction (ot, ots, 
inputAccountInfo) 
library.logger.debug ('before send raw tarnsaction', finalTransaction) 
const tid = await this. sendRawTransaction (finalTransaction) 
return tid 加 
} catch (e) { 
library.logger.error('Error: ', e.message) 





至 此 ， 提 现 的 流程 全 部 结束 。 


Asch 的 跨 链 实现 仍然 在 不 断 完善 ， 网 关 的 奖惩 机 制 、Bancor 协 议 等 也 都 在 逐步 实现 。 读 者 可 以 继续 去 Asch 的 源码 仓库 查看 最 新 的 实现 。 

































































利用 Asch 提 供 的 开发 工具 和 接口 ， 开 发 者 可 以 很 容易 地 开发 出 符合 自己 应 用 场景 的 区 块 链 应 用 。Asch 链 上 的 所 有 资产 ， 包 括 通过 跨 链 机 制 转移 过 来 的 其 他 主 链 的 资产 也 都 可 以 在 区 块 链 应 用 内 部 使 用 。 
对 于 Asch 来 说 ， 跨 链 资产 的 导入 丰富 了 Asch 的 “一 链 多 币 ” 的 生态 ， 生 态 里 的 DApp 开 发 者 都 可 以 导入 其 他 公 链 的 优质 资产 到 自己 的 DApp 内 使 用 。 













































































另外 ， 对 于 很 多 性 能 比较 差 的 公 链 来 说 ， 资 产 转移 到 Asch 链 可 以 极 大 地 提高 转账 效率 。 以 比特 币 为 例 ， 比 特 币 在 自己 的 链 上 每 秒 的 TPS 非 常 低 ， 并 且 一 般 需要 经 过 6 个 确认 (也 就 是 一 小 时 的 时 间 ) 才 被 
认为 是 安全 的 。 而 在 Asch 链 上 ， 基 于 Asch 的 DPoS+PBFT 的 算法 ，10 秒 就 可 以 进行 一 次 确认 ， 而 且 每 秒 可 以 达到 上 干 的 TPS。 手 续费 也 只 收 0.1 个 Asch 币 ， 这 对 比特 币 的 转账 效率 是 一 个 极 大 的 提升 。 




















9.4 ”本 章 总 结 














跨 链 技术 是 目前 公认 的 区 块 链 下 一 步 的 发 展 方向 。Asch 在 跨 链 领 域 率先 进行 了 探索 ， 并 且 实 现 了 和 一 些 公 链 的 跨 链 互通 。 希 望 读者 能 够 沿 着 本 章 的 内 容 继续 深入 探索 ， 这 个 领域 才刚 刚 开始 。 











参考 资料 : 
* Chain Interoperability : 


https://static1.squarespace.COmystatic/55f73743e4b051cfccO0b02cf/t/5886800ecd0f68de303349b1/1485209617040/Chain+lnteroperability.pdf。 
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. 第 12 章 DApp 测 试 














开发 区 块 链 应 用 目前 主要 有 以 下 三 种 方式 : 























“ 从 底层 开始 ， 从 零 开 始 打造 一 个 区 块 链 的 应 用 。 这 需要 实现 加 密 算 法 、P2P 通 信 以 及 共识 算法 等 。 这 种 方式 成 本 高 、 周 期 长 ， 并 且 技术 难度 也 非常 高 。 这 就 好 比 你 为 了 开发 一 个 Web 应 用 ， 可 能 先 需要 
自己 写 一 套 操作 系统 出 来 。 


“ 寻找 一 个 靠 谱 的 区 块 链 应 用 开发 平台 。 只 需要 关心 业务 逻辑 ， 关 心 应 用 和 区 块 链 结 合 的 部 分 就 好 ， 其 他 的 底层 技术 全 部 由 平台 提供 。 这 就 好 比 你 去 阿里 云 买 了 台 云 服务 器 ， 底 层 的 事情 不 用 关心 ， 只 
需要 部 署 你 的 代码 就 好 了 。 这 也 是 阿 希 链 在 区 块 链 时 代 所 做 的 事情 。 


“ 基于 其 他 的 区 块 链 应 用 改造 。 因 为 现在 代码 都 是 开源 的 ， 包 括 阿 希 链 也 是 。 你 完全 可 以 fo 引 其 他 项 目的 代码 根据 自己 的 需求 进行 修改 。 这 就 好 比 你 把 Linux 的 核心 代码 拉 过 来 ， 重 新 封装 成 一 个 发 行 
版 。 这 对 大 部 分 开发 者 来 说 也 是 没 必 要 的 。 











最 快 最 直接 的 方式 就 是 选择 一 个 区 块 链 平台 。 本 书 将 介绍 如 何 基于 阿 希 链 开发 一 个 区 块 链 应 用 (DApp) 。 我 们 会 带领 大 家 从 零 开始 开发 一 个 类 似 于 Hackernews 的 新 闻 媒 体 应 用 。 























第 10 章 ”DApp 设 计 与 开发 环境 搭建 





这 一 章 我 们 来 学 习 DApp 开 发 。 让 我 们 从 DApp 设 计 者 的 角度 ， 阐 述 如 何 从 零 到 一 设计 一 个 DApp， 在 这 个 过 程 中 我 们 会 发 现 ，DApp 与 传统 的 互联 网 服务 有 很 多 相似 之 处 ， 但 是 也 有 很 多 不 同 之 处 ， 这 
些 差异 会 影响 很 多 功能 实现 ， 甚 至 会 遇 到 一 些 使 用 传统 系统 开发 的 方案 无 法 解决 的 问题 。 通 过 解决 这 些 问题 ， 也 能 帮助 我 们 更 深入 地 理解 区 块 链 应 用 。 



































10.1 ”DApp 整 体 设计 


10.1.1 ”前 期 准备 








开发 之 前 我 们 需要 对 DApp 有 清晰 的 理解 与 认识 ， 包 括 技术 与 业务 需求 、Token 设 计 等 。 


















































如 果 我 们 面 对 一 个 中 心 化 的 系统 ， 可 能 只 需要 考虑 技术 与 业务 需求 ， 并 不 需要 关注 以 Token 为 中 心 的 经 济 设计 问题 ， 但 作为 一 个 去 中 心 化 应 用 ， 想 要 整个 生态 运转 良好 ， 应 该 充分 考虑 应 用 中 参与 者 在 
经 济 体 中 扮演 的 角色 ， 并 为 各 个 角色 设计 Token 的 使 用 场景 ， 包 括 如 何 流通 ， 如 何 消耗 ， 避 免 在 各 个 场景 中 出 现 不 可 控 的 问题 。 经 济 设计 需要 在 设计 阶段 充分 思考 ， 并 作为 需求 设计 的 重要 环节 。 
































那么 ， 一 个 好 的 经 济 设计 是 什么 样 的 呢 ， 在 笔者 看 来 ， 经 济 设计 应 当 满足 如 下 几 点 : 
.合理 激励 
.严格 保护 。 


' 公平 公开 。 








下 面 我 们 以 名 为 CCTime 的 DApp 为 例 ， 简 要 阐述 如 何 从 业务 、 经 济 、 代 码 三 个 层面 完成 DApp 的 设计 。 














10.1 ”DApp 整 体 设计 


10.1.1 ”前 期 准备 








开发 之 前 我 们 需要 对 DApp 有 清晰 的 理解 与 认识 ， 包 括 技术 与 业务 需求 、Token 设 计 等 。 


















































如 果 我 们 面 对 一 个 中 心 化 的 系统 ， 可 能 只 需要 考虑 技术 与 业务 需求 ， 并 不 需要 关注 以 Token 为 中 心 的 经 济 设计 问题 ， 但 作为 一 个 去 中 心 化 应 用 ， 想 要 整个 生态 运转 良好 ， 应 该 充分 考虑 应 用 中 参与 者 在 
经 济 体 中 扮演 的 角色 ， 并 为 各 个 角色 设计 Token 的 使 用 场景 ， 包 括 如 何 流 通 ， 如 何 消耗 ， 避 免 在 各 个 场景 中 出 现 不 可 控 的 问题 。 经 济 设计 需要 在 设计 阶段 充分 思考 ， 并 作为 需求 设计 的 重要 环节 。 
































那么 ， 一 个 好 的 经 济 设计 是 什么 样 的 呢 ， 在 笔者 看 来 ， 经 济 设计 应 当 满 足 如 下 几 点 : 
- 合理 激励 。 
适当 流通 。 
严格 保护 。 
- 公平 公开 。 


下 面 我 们 以 名 为 CCTime 的 DApp 为 例 ， 简 要 阐述 如 何 从 业务 、 经 济 、 代 码 三 个 层面 完成 DApp 的 设计 。 





10.1.2 ”业务 需求 描述 








CCTime 的 项 目 定位 是 基于 区 块 链 的 Hacknews， 作 为 分 享 信息 内 容 的 应 用 ， 鼓 励 创作 者 与 参与 信息 交流 者 ， 通 过 打 赏 和 点 赞 消耗 Token 的 形式 ， 促 进 整个 内 容 创 作 分 享 行为 的 活跃 与 可 持续 。 通 过 设计 
激励 规则 ， 实 现 了 一 个 简单 的 经 济 模型 。 




















根据 业务 需求 抽象 出 以 下 核心 场景 : 

“ 用 户 创建 频道 ， 作 为 内 容 容器 ， 可 在 容器 中 发 布 文章 或 新 闻 。 

“ 用 户 在 频道 中 发 布 文章 或 新 闻 ， 完 成 信息 分 享 。 

:用户 浏览 主页 内 容 ， 通 过 文章 热度 和 发 布 时 间 排序 内 容 。 

“ 用户 浏览 具体 内 容 ， 对 感 兴趣 的 内 容 进 行 评 论 或 回复 评论 。 

“ 用 户 打 赏 文章 作者 ， 根 据 不 同 模式 执行 不 同 的 奖励 结算 策略 。 

“ 默认 模式 ， 文 章 打 赏 Token 一 部 分 分 给 记 账 人 ， 男 一 部 分 结算 给 作者 。 

“ 抽奖 模式 ， 文 章 打 赏 Token 延 迟 结算 ， 暂 时 放 在 抽奖 池 中 ， 开 奖 之 后 实时 计算 ， 一 部 分 分 配给 记 账 人 ， 一 部 分 结算 给 作者 ， 另 一 部 分 结算 给 中 奖 的 打 赏 用 户 。 
: 抽奖 模式 下 ， 文 章 作者 或 受托 人 在 开奖 时 间 到 达 之 后 揭晓 抽奖 结果 。 


“ 抽奖 模式 下 ， 获 奖 的 用 户 在 开奖 之 后 的 文章 中 领取 奖励 。 





“ 默认 模式 中 的 结算 在 打 赏 时 实时 进行 。 


“ 受托 人 举报 频道 、 文 章 、 评 论 ， 举 报 超 过 三 次 后 ， 内 容 不 再 显示 。 


10.1.3 角色 


参与 DApp 中 的 角色 如 下 : 


“受托 人 


“ 文章 发 布 者 


“ 普通 用 户 


1. 受 托 人 角色 


受托 人 角色 相对 比较 固 
受托 人 角色 能 够 举报 管理 应 


但 受托 人 的 权利 也 不 能 过 大 ， 受 托 人 不 能 单 赁 主观 的 判断 去 认定 内 容 是 否 违规 ， 这 样 就 有 可 能 使 内 容 


免 造成 集权 情况 出 现 。 应 


2. 作 者 角色 






































定 ， 受 托 人 被 指定 





























当 用 户 发 布 了 信息 或 文章 后 ， 就 成 为 这 篇 内 容 的 作者 ， 同 时 拥有 了 获得 文章 打 赏 奖励 的 权利 











中 的 内 容 ， 仲 裁 者 行使 权力 ， 通 过 举报 功能 净化 整个 CCTime 应 





























的 内 容 环境 ， 防 止 应 


后 不 会 频繁 变化 ， 如 果 需 要 修改 受托 人 ， 目 前 的 版 本 需要 升级 后 实现 。 


























展示 完全 被 受托 人 控制 。 为 了 避免 这 样 的 情况 出 现 ， 受 托 人 的 权利 应 当 分 散 ， 采 








得 打 赏 奖励 拆 分 为 两 部 分 : 一 部 分 奖励 给 受托 人 ， 一 部 分 奖励 给 作者 。 抽 奖 模式 中 ， 文 章 打 赏 奖励 分 为 三 部 分 并 目 


抽奖 算法 结算 奖励 : 一 部 分 分 给 受托 人 ， 一 部 分 给 作者 ， 另 一 部 分 作为 抽奖 奖励 给 打 赏 的 幸运 








文章 作者 可 根据 

















优秀 的 文 
更 吸引 

















不 过 在 抽奖 模式 下 也 会 出 现 极 端 问题 ， 如 果 作 者 设置 了 抽奖 模式 的 文章 ， 但 没有 在 


题 应 该 不 存在 ， 直 接 设计 为 系统 自动 开奖 结算 ， 通 过 一 个 后 台 运行 的 守护 线程 就 能 够 完成 文章 抽奖 数 











必 益 








初始 化 时 受托 人 数量 为 5， 那 么 合约 设 为 : 如 果 举 报 的 受托 人 数量 超过 3 个 ， 就 过 滤 文 章 不 显示 在 列表 中 。 





按照 内 容 作 者 指定 的 结算 时 间 延 时 结算 ; 一 个 周期 内 的 打 赏 奖励 会 被 汇总 ， 周 期 结束 后 





会 排序 靠 前 ， 而 决定 其 是 否 优秀 的 判断 条 件 是 把 收 到 的 打 赏 金额 累计 ， 排 名 靠 前 
户 参 与 打 赏 ， 赚 取 额 外 














; 之 后 


3 








自己 的 需要 选择 文章 奖励 类 型 ， 也 能 够 根据 之 前 的 奖励 情况 设置 不 同 的 抽奖 模式 结算 周期 。 

















可 是 DApp 使 











这 样 自 动 结算 的 方式 就 要 慎重 考虑 ， 








虽然 自动 结算 可 以 通过 区 块 创建 的 村 




















步 的 负担 。 为 此 ， 需 要 采 

















回 到 结算 问题 上 ， 既 然 不 能 














手动 结算 ， 








效率 换 稳 定 ， 虽 然 和 传统 的 应 








开发 思路 相悖 ， 但 














疆 








自 芭 














， 那 么 就 
























































需要 对 上 面 提出 的 极端 问题 进行 专门 处 理 ， 这 时 候 可 以 引入 第 三 方 角色 进行 结算 操作 ， 由 


ET 





容 结算 策略 切换 为 默认 策略 。 


的 文章 作者 会 有 更 多 的 曝光 率 ， 从 而 吸引 更 多 的 打 赏 ， 获 得 更 高 


传播 不 良 信息 。 

















投票 的 机 制 ， 以 


和 指定 文章 结算 类 型 的 权力 。 目 前 支持 的 文章 结算 类 型 为 两 种 一 一 默认 模式 与 抽奖 模式 。 默 认 模 式 中 文章 所 























必 益 。 相 对 默认 模式 来 讲 ， 抽 奖 模式 可 能 会 














周期 结束 的 时 候 手动 触发 抽奖 程序 进行 奖励 结算 ， 这 就 损害 了 参与 打 赏 的 




















户 利益 。 如 果 在 中 心 化 的 系统 中 ， 这 个 问 





居 状 态 的 更 新 。 














也 是 目前 去 中 心 化 应 





为 评论 点 赞 。 当 然 也 有 创建 频道 、 发 布 文章 的 权限 。 






























































受 。 那 么 受托 人 角色 可 以 担 此 重任 ， 为 延 时 的 抽奖 类 型 的 文章 执行 抽奖 合约 。 
3. 用 户 
户 是 通用 角色 ， 可 以 评论 文章 ， 打 赏 文章 ， 回 复评 论 和 
中 心 化 的 应 用 中 ， 会 限制 普通 用 户 的 权限 ， 甚 至 会 要 求 
那么 在 去 中 心 化 的 应 用 里 ， 
审核 与 中 心 化 治理 。 





下 面 我 们 来 聊 一 聊 经 济 模型 的 





10.1.4 


经 济 模型 


J 








去 中 心 化 应 














人 一 定 的 激励 。 激 励 从 哪里 来 ?当然 是 合约 的 调 
这 样 就 建立 了 一 个 小 小 的 经 济 基础 循环 。 


中 流通 ， 





设计 。 


可 以 理解 为 一 系列 智能 合约 的 集合 ， 




















者 ， 





这 样 就 够 了 吗 ? 当然 不 是 ， 前 面 提 到 的 问题 还 没有 








频繁 调 











是 不 合理 的 ， 如 果 人 人 都 去 创建 自己 的 频道 ， 





而 言 ， 创 建 频道 和 创建 文章 的 消耗 是 差不多 的 ， 但 对 整 
高 创建 频道 合约 的 手续 费 来 限制 。 这 样 对 受托 人 来 说 ， 


合约 的 调 


个 应 























首要 考虑 的 问题 。 





户 没 有 可 以 与 现实 世界 身份 绑 定 的 方式 ， 在 系统 中 只 有 一 个 昵称 或 地 址 ， 作 恶 的 成 本 非常 低 ， 如 何 避 免 系统 功能 被 小 











解决 ， 虽 然 我 们 的 系统 没有 很 明显 的 权限 设 


， 也 就 是 任何 人 都 可 以 调 


























的 影响 是 不 同 

















b 是 合理 的 激励 ， 因 为 收 




















的 ， 因 为 一 个 频道 的 管理 成 本 和 认 知 
了 高 额 的 频道 创建 手续 费 而 有 频道 管理 的 义务 。 








其 实 调 整 手续 费 的 目的 是 规范 

















户 行为 ， 通 过 调 低 合约 手续 费 可 鼓励 








“ 对 优质 文章 进行 评论 ， 


刚才 提 到 了 受托 人 角色 可 以 通过 








如 果 评 





提供 计算 资源 来 获 


论 足 够 好 有 机 会 获 


“ 参与 抽奖 打 赏 ， 有 概率 获得 开奖 奖励 。 














如 何 吸引 

















引入 了 抽奖 的 模式 就 应 该 保证 抽奖 的 规则 完全 公平 ， 并 且 抽 奖 的 结果 是 不 可 能 


根据 打 赏 金额 的 权 各 


户 对 优质 的 文 





计算 ， 


行为 通过 奖励 策略 来 约束 。 








户 调 











得 作者 或 其 他 读者 的 赞赏 。 





进行 打 赏 呢 ， 抽 奖 算法 是 一 种 解决 方案 ， 收 集 一 个 
除去 受托 人 和 作者 的 奖励 ， 余 下 的 全 部 返还 给 中 奖 的 打 赏 者 ， 这 样 既 能 激励 参与 者 对 文章 进行 打 赏 ， 又 能 从 鼓励 创作 者 获得 更 多 的 




















每 个 人 可 以 重复 打 赏 





， 首 先 要 保证 每 个 人 的 打 赏 金额 在 奖池 中 所 占 的 比例 和 权重 


很 可 能 出 现 人 人 都 参与 很 小 金额 的 打 赏 ， 每 篇 文章 都 打 赏 一 遍 来 增加 





， 调 高 手续 费 可 限制 


可 以 通过 

















户 调 








周期 内 的 打 赏 金额 ， 在 周期 结束 之 后 汇总 ， 按 照 














取 Token 奖 励 ， 作 者 通过 文章 打 赏 来 获取 Token 奖 励 ， 那 么 用 户 有 什么 动机 参与 到 应 用 中 呢 ? 一 个 用 户 的 激励 来 自如 下 两 个 方面 : 




















有 权限 的 合约 ， 那 么 如 此 一 来 系统 会 面临 一 些 风险 ， 例 如 
不 但 受托 人 难以 管理 ， 也 会 改变 频道 存在 的 本 质 ， 进 而 影响 内 容 的 管理 ， 既 然 不 做 权限 的 限制 ， 就 要 借助 Token 对 合约 调 
成 本 ， 相 对 于 一 篇 文章 的 成 本 高 很 多 ， 所 以 在 频道 创建 的 处 理 上 ， 要 有 一 些 限制 ， 可 通过 提 


户 打 赏 的 金额 计算 出 获奖 的 比例 ， 通 过 随机 抽 选 的 方式 选 出 幸运 


件 处 理 函 数 实现 (后续 会 介绍 ) ， 但 是 面 对 未 知 数据 量 的 情况 下 ， 多 个 节点 产生 大 量 的 数据 会 造成 多 个 节点 同 


一 个 利益 不 相关 的 第 三 方 角色 去 执行 结算 更 容易 被 参与 者 接 


户 进 行 身份 认证 ， 手 机 绑 定 等 等 资料 ， 来 提高 其 作恶 的 成 本 ， 关 键 信息 的 创建 更 是 需要 中 心 化 的 组 织 审核 通过 后 生效 。 





























， 从 而 保证 应 








稳定 呢 ? 答案 是 通过 经 济 模型 代替 








智能 合约 执行 的 每 一 次 写 操作 ， 都 要 消耗 系统 计算 资源 ， 系 统 的 计算 资源 由 受托 人 提供 ， 那 么 为 了 保证 合约 的 顺利 执行 和 网 络 的 稳定 ， 就 需要 给 受托 
者 花费 一 部 分 Token 作 为 执行 合约 的 手续 费 ， 而 这 些 受托 人 获得 执行 手续 费 来 作为 维持 网 络 稳定 的 奖励 ，Token 可 以 通过 合约 在 两 个 角色 


: 频道 创建 合约 被 
进行 调整 。 对 服务 























的 费 














。 这 样 维持 一 个 平衡 ， 保 证 系统 不 会 出 现 不 可 控 的 情况 。 





























准确 预测 的 ， 那 么 抽奖 的 算法 就 需要 好 好 设计 ， 奖 池 中 的 金额 是 根据 所 有 的 打 赏 金额 汇总 而 来 ， 如 果 奖 励 完全 随机 ， 
自己 中 奖 概率 的 情况 ， 这 样 也 不 是 不 可 以 ， 但 从 整体 来 看 ， 不 利于 鼓励 优质 内 容 创作 者 获得 收益 。 所 以 这 种 


自己 不 断 追加 打 赏 额 而 增加 ， 这 里 包含 了 一 个 竞争 模型 ， 抽 奖 算法 如 果 考虑 权重 ， 


必 益 。 








不 




















激发 打 赏 的 





户 为 了 提高 














获奖 概率 ， 追 加 自己 的 打 赏 ， 这 对 内 容 的 生态 繁荣 是 一 种 推进 。 


业务 需求 和 经 济 模型 差不多 完成 设计 了 ， 下 面 进行 代码 设计 。 


10.1.5 ”代码 设计 








我 们 都 知道 ， 区 块 链 就 是 一 个 分 布 式 数据 库 ， 它 提供 了 读 写 接口 给 使 用 者 。 合 约 调用 写 服务 ， 接 口 提供 读 服务 ， 那 么 首先 需要 设计 合理 的 数据 库 结构 ， 承 载 读 写 功 能 。 




















依然 以 CCTime 为 例 ， 下 面 展示 数据 库 结构 的 设计 。 
1.channels 一 一 频道 


频道 是 文章 的 容器 ， 新 增 文章 要 指定 频道 ID， 且 频道 可 被 受托 人 举报 而 封禁 ， 频 道中 保存 了 文章 内 容 和 打 赏 数量 等 信息 ， 频 道 名 称 全 网 唯一 ， 不 允许 出 现 重复 。 参 见 表 10-1。 





表 10-1 频道 表 


EE 人 
Vv | | 
me | Mme | | Vv | | anwaa 
me | srw | 35 | | | mmo 
icon 256 | | | 频道 缩 略图 地 址 


articles 与 votes 作 为 统计 字段 对 当前 频道 下 的 内 容 数 量 和 打 赏 数量 进行 统计 。 


2.articles 一 一 文章 





文章 分 为 链接 与 内 容 两 种 形式 ， 结 算 类 型 分 为 默认 模式 与 打 赏 模式 ， 打 赏 模式 下 需要 给 文章 指定 结算 高 度 。 参 见 表 10-2。 


表 10-2 文章 数 表 

属性 类 型 长 度 | 非 空 备注 
Vv 
authorId stng |5 | | 创建 者 的 地 址 
timestamp | Nmber | | Vv | | 创建 的 时 间 戳 
ul 256 | | | 频道 缩 略 图 地 址 
reports | Number | | | 被 举报 次 数 
comments | Number | | Vv | 评论 数量 
settleHeight Bim | | “| 0o | 抽奖 模式 下 的 结算 高 度 
awardType | Nomber | | | 0o | 结算 模式 : 0 为 默认 ，1 为 抽奖 模式 
awardState | Number | | | 7-71 | 结算 状态 : 0 为 默认 ，1 为 未 结算 ，2 为 已 结算 


3.comments 一 一 评论 





评论 拥有 谋 套 结构 ， 可 以 评论 也 可 以 回复 评论 ，pid 字 段 作为 回复 节点 的 索引 保存 。 参 见 表 10-3。 


表 10-3 评论 表 


属性 类 型 长 度 默认 值 备注 
a | me | 1 | VvV | | Wm 
pos | wm | | 


4.votes 一 一 打 赏 


文章 打 赏 在 不 同 结算 模式 下 的 储存 有 不 同 的 储存 策略 。 参 见 表 10-4。 





表 10-4 打 货 表 

属性 类 型 “| 长 度 | 非 空 备注 
i ne | 10 |V| | 和 
voterId sving | 50 | | | 打 赏 者 的 地 址 
timestamp Number | |vV| | 创建 的 时 间 戳 
amount sung | 50 | | | 打 赏 金额 
type | Number | | V | 0 | 结算 类 型 : 0 为 默认 ，1 为 抽奖 模式 
awardState “| Number | | ”| -1 | 结算 状态 : 0 为 默认 ，! 为 未 结算 ，2 为 已 结算 
settleAmount | Number | | V | 0 | 中 奖金 额 ,未 中 奖 则 始终 为 零 











打 赏 在 不 同 的 模式 下 使 用 不 同 的 更 新 策略 ， 默 认 模式 每 一 次 的 打 赏 记录 作为 一 条 新 的 记录 保存 ;而 抽奖 模式 下 为 了 汇总 方便 (后 续 抽奖 合约 详 述 ) ， 同 一 地 址 的 打 赏 金额 会 在 一 个 记录 下 累加 ， 金 额 汇 
总 在 amount 字 段 中 。 同 时 创建 一 条 bids 记 录 ， 记 录用 户 在 当前 抽奖 周期 内 的 打 赏 记录 。 




















5.bids 一 一 抽奖 模式 下 的 打 赏 记录 
作为 抽奖 模式 下 打 赏 记录 的 一 种 补充 。 参 见 表 10-5。 


表 10-5” 打 赏 记录 表 


属性 类 型 长 度 非 空 备注 


a | sa | | Vv | | Wm 


数据 表格 设计 完成 ， 接 下 来 我 们 梳理 一 下 项 目 结构 。 


10.1.6 ”DApp 的 目录 结构 








DApp 的 目录 结构 与 普通 的 Web 项 目 相似 ， 只 不 过 Asch 为 了 主 网 的 稳定 和 安全 ， 对 侧 链 的 DApp 进 行 权限 保护 ， 通 过 VM 的 方式 包装 了 一 个 沙 盒 ， 为 沙 盒 注入 处 理 合约 需要 的 函数 或 全 局 对 象 ， 比 如 
app、blocks、trs 等 对 象 。 























如 下 所 示 的 contract 目 录 ， 就 是 载 入 JavaScript 虚 拟 机 中 执行 ， 这 样 既 可 以 保证 合约 的 图 灵 完 备 性 ， 又 可 以 把 DApp 可 能 造成 的 风险 控制 在 安全 的 范围 内 。 合 约 本 质 上 也 是 服务 ， 只 不 过 这 些 服务 执行 了 
写 操作 ， 所 以 就 和 接口 目录 中 负责 读 服务 的 代码 分 开 了 。 虽 然 “ 合 约 ”与 “接口 ”是 按照 读 写 职责 分 离 的 ， 但 是 在 结构 设计 的 时 候 依 然 是 以 实际 的 需求 为 主 。 示 例 目录 结构 如 下 : 



























































// 目录 结构 
| 一 .eslintrc.js =-- eslintrc 配置 
| 一 .gitignore -- git 配置 文件 
[— README .md 
| 一 blockchain.db 一 数据 库 文件 
| 一 config.json 一 Dapp 配置 文件 ， 存 放 受 托 人 私 钥 信 息 
| 一 contract =-- 合约 目录 ， 所 有 的 合约 存放 在 此 
cctime.js be CCTime 核 站 辑 
| 一 interface 人 数据 查询 接口 目 
[一 index.js 二 | 代码 文件 
| 一 DApp.json be 
| 一 genesis.json 一 人 x 块 内 容 
| 一 init.js -- DApP 初始 化 文件 ， 包 含 合约 注册 和 合约 设置 ， 稍 后 会 详 述 
| 一 1ib == 工具 
| 一 constants.js -- 常量 文件 
[一 interval-cache.js -- 接口 端 缓存 文件 
-一 utils.js -- 工具 函数 ， 抽 奖 算法 等 
| 一 1ogs -- 日 志 目录 ， 包 含 了 DApp 运行 的 1og，1og 等 级 可 根据 需求 调整 
[一 debug.20180426.1og -- 当天 会 生成 新 的 | 1 志文 件 
[mogel -- 模型 目录 
一 article.js 
-一 bid,.js 
| 一 channel.js 
| 一 comment .js 
| 一 report .js 
-一 vote.js 
[— Package.json 
— pvublie 
[一 index.html 
[一 test -- 测试 目录 
|- 一 cctime.js 
一 ,lib 一 测试 使 用 工具 库 
base.js 
utils.js 





下 面 我 们 对 项 目 结构 中 较为 核心 的 文件 进行 简要 讲解 。 





1.blockchain.db (数据 库 文件 ) 


























这 是 去 中 心 化 应 用 的 核心 文件 ， 所 有 的 数据 经 过 多 节点 验证 确认 之 后 都 会 储存 在 这 里 ， 如 果 DApp 有 多 个 受托 人 那么 db 文件 就 会 存在 多 个 副本 。 有 兴趣 的 读者 可 以 用 SQLite3 客 户 端 打开 看 一 看 其 中 的 数 
所 模型， 当然 也 能 找到 区 块 结构 和 自己 设计 的 模型 表 ， 不 过 这 个 文件 要 等 到 侧 链 启动 成 功 之 后 才 会 出 现 。 

















2.configjson (配置 文件 ) 





这 是 存放 着 受托 人 助 记 词 的 文件 ， 这 里 需要 说 明 一 点 ， 区 块 的 打包 和 确认 是 需要 达到 一 定 的 验证 数量 ， 才 能 写 入 到 链 上 ， 也 就 是 写 入 blockchain.db 文 件 中 ， 那 么 受托 人 配置 就 是 指定 受托 人 身份 。 可 以 
多 个 节点 配置 多 个 受托 人 (每 个 节点 一 个 受托 人 ) ， 也 可 以 单个 节点 配置 多 个 受托 人 ， 也 就 是 一 台 机 器 多 个 受托 人 。 




















我 们 在 初始 化 DApp 时 ， 命 令 行 工具 会 让 我 们 指定 受托 人 数量 ， 当 前 允许 的 最 小 数量 为 5， 那 么 测试 节点 的 受托 人 配置 就 是 单机 节点 配置 5 个 受托 人 ， 如 下 所 示 : 








"peers": [], // 六 测试 环境 暂 不 配置 
"secrets": [ // 受托 人 配置 
"fit night someone unveil dwarf believe middle evidence puzzle hotel 
common choose", 
"lawsuit ride civil slice kitchen unfold unable lumber prevent suspect 
finger chunk", 
"absurd sweet blast dinner battle zero ladder steak coral fork venture 
coffee", 
"topic ramp throw cloud moment jungle bar series task protect erupt 
answer"™, 
"hoot tired know dish rally kiwi snack patrol bunker ocean panel this" 











我 们 看 到 ， 这 是 作为 测试 节点 的 单机 配置 。 虽 然 是 单机 ， 但 依然 要 配置 至 少 5 个 受托 人 才能 生产 区 块 。 这 里 需要 的 受托 人 并 不 是 物理 节点 的 受托 人 (实际 中 的 5 台 机 器 ) ， 而 是 需要 这 些 私 钥 对 区 块 进行 
签名 ， 可 以 理解 为 五 名 受托 人 在 同一 个 节点 达成 共识 ， 签 名 区 块 ， 就 能 把 数据 写 入 链 上 ， 实 际 上 按照 Asch 的 PBFT (拜占庭 容错 算法 ) 只 需要 区 块 达到 三 分 之 二 以 上 的 受托 人 签名 即 可 写 入 区 块 。 













































































因此 ， 我 们 要 从 共识 的 机 制 去 理解 受托 人 和 节点 的 不 同 ， 这 有 助 于 我 们 获得 应 用 开发 和 部 署 设 计 的 全 局 视野 。 








另外 ， 受 托 人 不 仅 可 以 打包 区 块 ， 也 是 一 种 特殊 权限 的 角色 ， 下 一 章 会 详细 阐述 。 


3.genesisjson ( 创 世 区 块 ) 








创 世 区 块 就 是 链条 的 起 点 ， 也 是 预 置 在 DApp 启 动 之 前 的 ， 里 面包 含 了 创始 区 块 的 所 有 信息 ， 结 构 如 下 : 








"delegate": "0926b2269dlf6b7f194ef57c548cc7a3f340fb06156ea31014ab7bd9e562 
fblS", 
"height": 1, 
"pointId": null, 
"pointHeight": null, 
"transactions": [ 
{ 
"fee": "0 
"timestamp": 0, 
"senderPublicKey": "63a3e14d14f802b739e4326c832f2b827ca05146e8f9880421a 
1663b1bb97b7f", 
DG 3 
"args": "[\"XCT\",\"10000000000000000\",\"AAjoobuMcmkQ1gS8vTfBy3dQavBiH 
7sBCE\"]", 
"signature": "f3876e5859a02a205c72c3858da822e49ccf0846aa2033ed21ff847ff 
bdfc4ec27bb7a90b8872966eca46ce584cal3eca4ed35d74ed1077652d6236d30bce105", 
"id": "3c7f2c31f512002eefc7a767d33a18bdq8a33e353b4315ea4e7daa78797fflcb9" 


} 


]， 

"timestamp": 0, 

"payloadLength": 105, 

"payloadHash": "44480588769834334f75551ffe36c4a98667bfled22cdce104697e8bf92 
1639c", 

"count": 1, 

"signature": "lb0c187956d2f0clc5e209e08f9ca09b7a9196ad07a40ab4edbae7e960a23 
3999f3367fab0al13b9ca75e4ac30eed51a966fc15d4041c2f6f88e2140407acf09"， 

"id": "f923a4de1d6093046eff80e737eadfc520656f70802e47dccb5c99304bf9909d" 














这 个 结构 与 blockchain.db 中 的 结构 相同 ， 也 是 节点 之 间 广 播 同 步 区 块 所 使 用 的 数据 格式 。 其 中 : 











“ delegate: 产 块 受托 人 ， 侧 链 的 受托 人 同样 按照 顺序 产 块 ， 使 用 命令 行 注册 DApp 的 时 候 录入 过 受托 人 信息 ， 那 么 创始 区 块 的 delegate 属 性 也 是 五 个 受托 人 其 中 一 个 的 公 钥 。 


' height: 必须 是 1。 
“ pointId: 主 链 区 块 的 block ID。 


: pointHeight: 主 链 区 块 的 高 度 。pointId 与 pointHeight 都 是 为 了 与 主 链 同步 验证 而 使 用 的 ， 如 果 侧 链 区 块 中 的 pointId 和 pointHeight 与 其 他 的 节点 不 同 ， 那 么 就 表示 与 主 链 的 区 块 不 同步 了 。 为 什么 要 保证 
与 主 链 的 区 块 同步 呢 ， 这 涉及 主 链 资 产 与 侧 链 的 交互 ， 保 证 主 侧 链 的 资产 安全 。 


“transactions: 合约 交易 记录 ， 这 些 合约 涉及 区 块 之 间 的 同步 。 首 先 ， 交 易 的 记录 在 创建 后 在 节点 之 间 广 播 ， 这 些 被 广播 的 交易 就 存放 在 当前 的 区 块 数据 中 ， 十 秒 周 期 结束 之 后 ， 节 点 开始 验证 区 块 ， 按 
照 广播 顺序 验证 合约 。 我 们 也 看 到 交易 里 存放 了 很 多 条 合约 执行 的 记录 ， 包 括 转账 与 自 定义 合约 等 ， 这 些 合约 参数 在 各 个 节点 中 都 可 以 执行 并 验证 。 最 后 判断 是 否 同步 ， 如 果 同 步 则 写 入 区 块 ， 不 同步 则 回 
滚 区 块 。 


数据 结构 如 下 : 
“ fee: 合约 执行 的 手续 费 ， 按 照 bignum 的 类 型 储存 timestamp 合 约 执行 时 的 时 间 蕉 。 
“senderPublicKey: 合约 调用 者 的 公 钥 。 
' type: 合约 类 型 。 
“ args: 合约 执行 参数 列表 。 
“signature; 合约 调用 者 签名 的 Id。 
“ payloadLength: 作为 验证 区 块 中 发 生 交易 的 数据 长 度 。 
“ payloadHash: 区 块 中 交易 的 hash 摘 要 。 
“ count: 区 块 中 发 生 的 交易 数量 。 
' signature: 区 块 生产 者 的 签名 。 


整个 区 块 的 信息 分 析 完 毕 ， 下 面 我 们 继续 看 一 人 DApp 的 配置 文件 。 





4.DAppjson (应 用 元 信息 ) 


这 个 文件 是 在 根据 主 链 注册 DApp 的 环节 中 填写 的 参数 生成 : 





{ 
"name": "cctime", 
"link": "https://github.com/AschPlatform/asch-DApp-cctime/archive/master.zip", 
"category": 1, 
"description" : "Decentralized news channel", 
"tags": "asch, DAPP, demov cctime"， 
"icon": "http://07dyh3wOx.bkt.clouddn.com/cctime.png", 
"Eype™: 07 
"delegates": [ 
"afdf69f0da9ff333218f2cdl0cb0a907c2e76788f752b799cbldab3a9f03bf63", 
"67dq52a0265f9e5366660c8b384cee56d3f8b5737b2dqd3c617d22df83b5ebef02"， 
"39c2322600a0c8lecfa97119ec8e2d5bfb73394914d92b54e961846a987e4e22" 
"4740d2c16bf6c5al74ebale0f859253a64851d30acbc9655b01394af82d3e325", 
"b433c226645981477642491f77de7b8d63274aa51f932bbelfe3f445a8aaecc9" 
]， 
"unlockDelegates": 3 
} 





其 中 : 

“icon: 作为 生成 应 用 头像 的 外 部 ut 地址， 用 于 在 主 链 的 应 用 展示 。 

“ delegates: 是 侧 链 中 各 个 受托 人 公 铀 。 

“ unlockDelegates: 从 DApp 跨 链 转账 资产 时 需要 多 少 个 受托 人 联合 签名 ， 该 数字 必须 大 于 等 于 3、 小 于 等 于 你 配置 的 受托 人 公 钥 个 数 且 小 于 等 于 101， 数 字 越 大 越 安全 ， 但 效率 和 费用 越 高 。 


5.initjs (初始 化 文件 ) 





初始 化 文件 作为 DApp 启 动 的 入 口 文件 ， 每 次 主 链 启动 的 时 候 都 会 运行 initjs， 它 的 功能 如 下 : 











“ 注册 合约 。 


:初始 化 查询 缓存 文件 。 
: 注册 DApp 事 件 监 听 。 
配置 logger 等 级 。 

' 设置 默认 消耗 Token。 


代码 如 下 : 





// 初始 化 文件 


const IntervalCache = require('./lib/interval-cache') 


module.exports = async function() { 
app.1logger.setLevel ('debug') 
app.1logger.info('enter DApp init') 


app.registerContract (1000, 'cctime.postArticle') 
app.registerContract (1001, 'cctime.postComment') 
app.registerContract (1002, 'cctime.voteArticle') 
app.registerContract (1003, 'cctime.likeComment') 
app.registerContract (1004, 'cctime.report') 
app.registerContract (1005, 'cctime.createChannel') 
app.registerContract (1006, 'cctime.updateChannel') 


app.registerContract (1007, "cctime.getReward') 
app.registerContract (1008, 'cctime.calculatePrize') 


app.setDefaultFee ('10000000', 'CCTime.XCT') 
app.registerFee (1007, '0') 

app.registerFee (1005, '1000000000000') 
app.registerFee (1006, '50000000000') 


app.custom.cache = new IntervalCache (10 * 1000) 


// await app.sdb.1load( 
'Vote', 


// ['awardState', ‘amount', 'voterId', 'timestamp', 'aid', 'id', 
'settleAmount', 'type'l], 

1 [Tidi tveterIari "aid'l] 

a 

// await app.sdb.load('Channel', ['name', 'reports', 'id'], ['id']) 


(1) 注册 合约 











app.registerContract 传 入 合约 类 型 与 合约 目录 中 定义 的 方法 ， 合 约 类 型 就 是 我 们 在 区 块 信息 中 看 到 的 transactions 数 组 中 的 type 属 性 ，DApp 内 置 了 三 种 合约 默认 合约 : 





" DApp 提 现 ，type=2 
. 内 部 转账 ，type=3 


“ 设置 昵称 ，type=4 











其 余 的 自 定义 合约 需要 通过 接口 注册 才能 作为 服务 调用 。 











(2) 设置 合约 手续 费 











合约 手续 费 是 DApp 经 济 模型 的 一 种 重要 体现 ， 我 们 鼓励 哪些 合约 ， 限 制 哪些 合约 ， 都 是 通过 Token 消 耗 来 完成 的 ， 手 续费 不 仅 是 用 作 激 励 也 是 对 服务 器 与 网 络 稳定 的 一 种 保护 。 


























手续 费 设置 方式 是 ， 先 注册 默认 的 合约 消耗 费 与 币 种 setDefaultFee， 这 里 也 强调 一 点 ，Asch 的 侧 链 应 用 是 可 以 使 用 多 种 Token 进 行 结算 和 消耗 的 ， 这 样 我 们 可 以 实现 一 个 支持 多 币 种 的 DApp， 如 果 未 
来 Asch 主 链 实现 了 跨 链 互通 之 后 ， 也 可 以 对 接 链 外 资产 充值 到 侧 链 内 部 使 用 。 







































































设置 完 默认 手续 费 之 后 ， 可 以 设置 单个 合约 费用 ， 这 里 的 费用 都 是 用 bjignumber 形 式 的 字符 串 格式 传 入 ， 需 要 考虑 精度 问题 。 





















































这 里 我 们 把 创建 频道 的 手续 费 设置 为 1000 XCT， 更 新 频道 的 手续 费 设 置 为 500 XCT， 目 的 是 限制 这 些 重要 数据 的 频繁 变动 ， 因 为 在 社 群 论坛 中 ， 很 少 出 现 修改 版 面 或 频道 的 情况 ， 而 且 这 些 信息 的 修改 
会 造成 比较 大 的 影响 ， 所 以 我 们 在 合约 调用 上 进行 了 限制 。 


























(3) 设置 缓存 文件 























app.custom.cache=new IntervalCache (10*1000) 这 段 代码 维 护 了 一 个 全 局 的 map， 每 十 秒 钟 会 清空 map 中 的 内 容 ， 这 些 内容 是 在 接口 的 一 些 查询 中 进行 维护 ， 每 个 区 块 打包 周期 之 后 进行 数据 清 
空 ,保证 缓存 的 数据 为 最 新 数据 。 该 文件 会 在 接口 编写 章节 详细 说 明 。 








(4) 注册 DApp 事 件 监听 








app.registerHook ("beforeCreateBlock'，function) 在 CCTime 中 并 没有 用 到 ， 但 是 值得 花 一 些 篇 幅 叙 述 一 下 ， 这 些 事件 作为 每 次 区 块 生成 之 后 的 hook 函 数 ， 可 以 实现 一 些 业 务 逻 辑 ， 但 是 这 里 并 不 
建议 使 用 监听 函数 做 过 多 的 操作 。 为 了 保障 系统 的 稳定 ， 避 免 在 每 次 区 块 调用 的 时 候 执行 过 重 的 查询 与 写 入 ， 可 以 将 一 些 批量 执行 的 操作 分 散在 合约 执行 之 中 完成 。 也 避免 了 过 重 的 批 处 理 逻 辑 执行 阻塞 查 
询 或 写 入 ， 严 重 的 也 可 能 会 造成 区 块 回 滚 。 















































































































































所 以 在 使 用 监听 函数 的 时 候 ， 一 方面 要 考虑 到 执行 性 能 ， 另 一 方面 要 设计 好 数据 写 入 的 隔离 。 例 如 我 们 想 要 用 事件 监听 的 方式 实现 更 新 某 种 类 型 的 数据 字段 ， 那 么 最 好 能 够 保证 在 数据 更 新 的 时 候 没有 
其 他 的 合约 会 修改 这 些 数据 ， 换 名 话说， 就 是 保证 自动 执行 的 数据 不 会 与 用 户 调用 的 合约 写 入 造成 冲突 。 


























6.logs (日 志文 件 ) 








日 志文 件 中 每 天 会 生成 新 的 文件 ， 文 件 内 容 包 含 了 区 块 侧 链 中 区 块 信息 和 相关 的 错误 记录 。 








7.model (数据 模型 ) 











这 里 存放 了 所 有 的 数据 模型 ， 数 据 库 的 设计 在 前 面 已 经 详细 说 明 ， 这 里 不 再 玲 述 ， 感 兴趣 的 朋友 可 以 去 源码 库 学 习 : https://github.com/AschPlatform/DApp-book- 


code/tree/master/cctime/model, 


8.test (测试 目录 ) 

















测试 目录 中 包含 合约 与 接口 的 测试 代码 ，lib 目 录 中 有 测试 使 用 的 工具 库 ， 详 细 内 容 会 在 之 后 的 章节 详 述 。 








到 这 里 我 们 就 完成 了 整体 项 目 结构 的 介绍 ， 梳 理 了 大 致 的 项 目 概念 ， 接 下 来 就 是 动手 开发 了 。 


10.2 开发 环境 搭建 








基于 阿 希 链 开 发 一 个 DApp， 首 先 需要 开发 者 有 一 定 的 JavaScript 基 础 。 在 此 基础 上 通过 前 两 部 分 的 学 习 ， 也 掌握 了 一 定 的 区 块 链 技术 基础 。 这 时 就 可 以 根据 自己 的 需求 开发 一 个 DApp 了 。 在 正式 开发 
之 前 ， 我 们 首先 来 配置 开发 DApp 所 需要 的 环境 。 

















10.2.1 ”Asch 的 网 络 类 型 





Asch 有 三 种 网 络 类 型 ， 分 别 是 localnet、testnet 和 mainnet。 其 中 localnet 是 跑 在 本 地 节点 ， 后 两 种 是 发 布 到 线 上 的 ， 可 通过 公 网 访问 。 下 面 对 这 三 种 网 络 做 一 个 介绍 : 





“localnet: 是 运行 在 本 地 、 只 有 一 个 节点 〈101 个 受托 人 都 配置 在 本 地 的 configjson 文 件 中 ) 的 私 链 ， 主 要 是 为 了 方便 本 地 测试 和 开发 。locanet 就 是 私有 链 。localnet 创 建 完 成 后 使 用 密码 “someone manual 


strong movie toof episode eight spatial brown soldier soup motor” 登录 钱包 可 以 获取 1 亿 的 测试 币 。 


“ testnet: Asch 链 公 网 测试 环境 ， 由 多 个 服务 器 组 成 ， 具 备 完整 的 P2P 广 播 、 分 布 式 存储 等 ， 在 功能 上 下 mainnet 一 致 ， 和 mainnet 的 区 别 在 于 magic 不 同 〈 可 以 理解 为 用 于 区 分 不 同 链 的 id， 目 前 Asch testnet 
的 magic 为 594fe0f3 ，mainnet 的 magic 为 555b3cf5) 。testnet 的 测试 币 需要 向 团队 申请 。 


mainnet: Asch 主 网 正式 环境 (http://wallet.asch.io) ， 这 个 网 络 中 的 XAS Token 会 在 各 大 交易 平台 进行 交易 ， 具 有 实际 的 价值 。 
我 们 建议 开发 者 在 进行 DApp 开 发 时 ， 遵 循 以 下 流程 : 
第 一 步 ， 在 localnet 开 发 、 本 地 调试 。 


第 二 步 ， 部 署 到 testnet， 在 testnet 进 行 测试 。 





第 三 步 ， 部 署 到 mainnet， 项 目 正式 发 布 。 














接 下 来 我 们 会 讲解 配置 localnet 的 流程 。 


10.2.2 ”配置 localnet 


1. 推 荐 服务 器 配置 
操作 系统 : Ubuntu 16.06 x64 Node.js 版 本 : 8.x.x。 
2. 安 装 依赖 


更 新 系统 软件 : 





apt update 
apt Upgrade 





安装 依赖 : 





apt install curl sqlite3 ntp wget git libssl-dev openssl make gcc g++ 
autoconf automake python build-essential -y 
apt install libtool libtool-bin -y 





安装 node.js (已 安装 的 可 跳 过 ) : 





curl -o- https://raw.githubusercontent .com/creationix/nvm/v0.33.2/install.sh 
| bas 

export NVM DIR="$HOME/ .nvm" 

[ -s "$NVM DIR/nvm.sh" ] && \. "$NVM DIR/nvm.sh" 

[ -s "$NVM DIR/bash completion" ] && \. "$NVM DIR/bash completion" # This 
loads nvm bash completion 


nvm install 8 





3. 安 装 Asch 


从 GitHub 克 隆 源 代码 : 





git clone https://github.com/AschPlatform/asch && cd asch && chmod utx aschd 





安装 依赖 包 : 





npm install 





上 一 步 如 果 安 装 失败 ， 请 删除 目录 node_modules， 多 试 几 次 。 








启动 应 











./aschd start 








如 果 前 面 几 步 安 装 正确 ， 此 时 aschd 应 该 正常 启动 了 。 可 以 使 用 netstat-nltp 检 查 4096 端 口 是 否 启动 。 














访问 前 端 页 面 。 此 时 访问 http://your-ip:4096， 返 回 内 容 如 下 : 








{ 
success: false, 
error: "Error: Failed to lookup view "wallet.html" in views directory "/ 
root/asch/public/dist"" 











不 用 担心 ， 这 是 正常 的 ， 接 下 来 我 们 构建 钱包 的 前 端 界面 。 











4. 构 建 钱包 前 端 界面 


前 端 界面 可 以 直接 到 http://china.aschcdn.com/frontend-localnet.zip 下 载 并 解压 到 asch 目 录 里 的 public/dist 目 录 。 也 可 以 基于 asch-frontend-2 仓 库 (https://github.com/AschPlatform/asch- 


frontend-2) 自行 编译 。 














此 时 登录 http://your-ip:4096， 就 可 以 看 到 和 主 网 一 样 的 钱包 界 


on 








5.localnet 的 账户 和 受托 人 


所 有 的 localnet 里 使 用 主 密码 “stone elephant caught wrong spend traffic success fetch inside blush virtual element” 登 录 之 后 会 有 1 亿 个 XAS。101 个 受托 人 信息 记录 在 config.json 中 ， 受 托 人 
的 余额 随 着 区 块 的 锻造 而 不 断 增长 。 





10.2.3 DApp Demo 


1. 安 装 asch-cli 



































作为 Asch 提 供 的 命令 行 开发 工具 ，asch-cli 提 供 了 一 系列 在 命令 行 下 操作 区 块 链 的 方法 ， 下 面 会 用 到 DApp 相 关 的 命令 ， 所 以 需要 先 安装 asch-cli: 











npm install -g asch-cli 





2. 创 建 受 托 人 账户 








每 个 DApp 都 有 独立 的 受托 人 ， 这 些 受 托 人 负责 区 块 的 生产 、 资 产 的 转账 并 且 获 取 手 续费 。 一 个 DApp 最 少 有 5 个 受托 人 ， 最 多 101 个 。 在 注册 DApp 之 前 ， 需 要 先生 成 受托 人 ， 收 集 受 托 人 的 公 钥 。 











使 用 asch-cli crypto-g 来 生成 账户 ， 需 要 输入 想 要 生产 的 账户 个 数 : 











root@iZ2ze7j0sus9exe3j2whbc2Z:~# asch-cli crypto -9 
? Enter number of accounts to generate 5 
[ { address: 'AQlFeHhivlFQ2cvhNiuceWVcH7vVHMkv9s', 
secret: '‘'olympic cushion neither ill like dutch sound attract panel 
nation road recall', 
publicKey: '0352486d87c928918638c8al3c7e4765f2c9fa075318bd680b8d95elcf1d6 
16E* J} 
{ address: 'A8RDwpDFLAkiJ6u81wRUgqPFSJqmeq32Ha2z", 
secret: 'hobby gather joke draft crisp author mixed media wide target 
romance save', 
publicKey: 'cbb3671d343628fe03fba2f0139b783a7b86445f79ee55c99bf5bbe380e4 
fb46' }, 
{ address: 'A33Pnj7wDAJKfG2RcWJdomWdUmcnw52MP6', 
secret: 'broccoli arm wine festival suffer supply tourist brown jump plug 
base caught', 
publicKey: '2f23a9659e32032910b8e078c0c980c6cb7c3a052a235a59079bfd6d608e 
ecg5t Fy 
{ address: 'AM5Y6wsb7n5QUu6X2Qfu8vqNYoncD1L6YRYy', 
secret: 'meadow mesh virus video envelope defy fire price feel board 
together chat', 
publicKey: '351c081c470f£41620f4709b6b3ca3721dc920d4e528b27b8fa4d88635e5 
3e128"' }, 
{ address: 'A2MpzHYG60Rnbsyrh7AZPg6oDtG8Drzgci', 
secret: 'crisp sudden segment magnet concert leisure tank iron satisfy 
hint story floor', 
publicKey: 'cbd808111a08081f7dc93aafd9fe26a70216e3f42d927660ab8d15b7bdf89 
98c' } ] 
Done 





3. 创 建 模 板 应 用 


asch-cli dapps 提 供 了 一 系列 管理 DApp 的 命令 : 





root@iZ2zeclphkwlg90eglqdw82:~# asch-cli dapps -h 
Usage: dapps [options] 
manage your dapps 
Options: 


add new dapp 

deposit funds to dapp 
—w, --withdrawal withdraw funds from dapp 
-i ~"install install dapp 

uninstall dapp 

create genesis block 
output usage information 


























我 们 这 里 使 用 -a 来 添加 一 个 新 应 用 。 











创建 dapp 目 录 : 





mkdir asch-dapp-test 
cd asch-dapp-test 











创建 应 











root@i22ze7j0sus9exe3j2whbc2Z:~/asch-dapp-test# asch-cli dapps -a 

Copying template to the current directory http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 
? Enter DApp name helloworld 

Enter DApp description demo 

Enter DApp tags asch 

Choose DApp category Common 

Enter DApp link http://yourdomain/dapp.zip 

Enter DApp icon Url http://yourdomain/logo.png 

Enter public keys of dapp delegates - hex array, use ',' for separator 
0352486987c928918638c8al3c7e4765f2c9fa075318bd680b8d95elcf1d616f, cbb3671d3 
43628fe03fba2f0139b783a7b86445f79ee55c99bf5bbe380e4fb46, 2f23a9659e32032910b 
8e078c0c980c6cb7c3a052a235a59079bfd6d608ecc95, 351c081c470f41620f4709b6b3 
ca3721dc920d4e528b27b8fa4d88635e53e128, cbd808111a08081f7dc93aafd9fe26a70216 
e3f42d927660ab8d15b7bdf8998c 

? How many delegates are needed to unlock asset of a dapp? 3 

App meta information is saved to ./dapp.json http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 
? Enter master secret of your genesis account [hidden] 

? Do you want publish a inbuilt asset in this dapp? Yes 

? Enter asset name, for example: BTC, CNY, USD, MYASSET XCT 

?3 

? 


2 
2 
? 
? 
? ' 


Enter asset total amount 100000000 
Enter asset precision 8 
New genesis block is created at: ./genesis.json 





上 面 的 命令 完成 后 ， 创 建 一 个 DApp 所 需 的 文件 基本 都 生产 了 。 
说 明 : 


: DApp link: 为 了 方便 用 户 自动 安装 ， 链 接 必须 以 .zip 结 尾 。 这 个 链接 不 要 求 一 定 存在 ， 如 果 未 打算 开源 可 以 输入 无 效 地 址 。 














" DApp icon url: 该 选项 表示 应 用 的 logo， 用 于 在 阿 希 链 的 应 用 中 心 展 示 ， 要 求 以 .jpg 或 .png 结 尾 。 如 果 该 链接 失效 ， 则 应 用 中 心 会 展示 一 个 默认 图 标 。 


:How many delegates ate needed to unlock asset of a dapp: 这 个 选项 表示 从 DApp 跨 链 转账 资产 时 需要 多 少 个 受托 人 联合 签名 ,该 数字 必须 大 于 等 于 3、 小 于 等 于 你 配置 的 受托 人 公 负 个 数 且 小 于 等 于 101， 


数字 越 大 越 安全 ， 但 效率 和 费用 越 高 。 
:Enter master secret of your genesis account: 这 里 是 创 世 账 户 ， 如 果 发 行内 置 资产 ， 那 么 最 初 的 资产 都 在 这 个 账户 里 。 


”Do you want publish ainbuilt asset in this dapp: DApp 可 以 创建 内 置 资产 ， 但 该 内 置 资产 只 能 在 DApp 内 部 使 用 ， 无 法 转 回 到 Asch 主 链 。 一 般 建 议 在 主 链 发 行 UIA (用 户 自 定义 资产 ) ， 然 后 将 资产 充值 到 
DApp 中 ， 充 分 享受 Asch 侧 链 架 构 的 优势 。 


4. 在 主 链 注册 DApp 
在 正式 部 署 DApp 之 前 ， 需 要 先 在 主 链 注册 。 注 册 需 要 消耗 100 XAS， 这 里 我 们 先生 产 一 个 账号 ， 然 后 对 其 充值 ， 再 然后 用 这 个 账号 来 注册 DApp。 


生成 一 个 账号 : 





root@i2Z2ze7j0sus9exe3j2whbc2:~# asch-cli crypto -9 
? Enter number of accounts to generate 1 
[ { address: 'AcL2PfkKURQHWzFi6iKRZGsESzhWUTvtNn', 
secret: 'remove sand cushion hobby royal voice game pony bounce sketch 
enact blast', 
publicKey: '5ce5d531b3cf4168e4487dq985a0c9fd52c96fe74b3eddlec8a9ac159c8 
5e5289' } ] 
Done 








使 用 localnet 的 创 世 账 号 对 其 转账 : 








root@i2Z2ze7j0sus9exe3j2whbc2:~# asch-cli sendmoney -e "someone manual strong 
movie roof episode eight spatial brown soldier soup motor" -a 100000000000 
-t AcL2PfkURQOHWzFi61KRZGSESzhWUTVvtNn 

1c368edaa65316611e5ae8e774943ea97104flb0dq703a4a0812e533bc4ccedca 





返回 交易 id， 这 里 -a 后 面 的 单位 为 最 小 单位 。 查 询 余额 : 








root@i2Z2ze7j0sus9exe3j2whbc2Z:~# asch-cli getbalance AcL2PfkURQHWzFi6iKRZGsESz 
hWUTvtNn 
100000000000 





注册 应 用 : 





root@i22ze7j0sus9exe3j2whbc2:~/asch-dapp-test# asch-cli registerdapp -f dapp. 
json -e "remove sand cushion hobby royal voice game pony bounce sketch 
enact blast" 

7251e913394b521409d13310c50a938ad8a0a76e185a7d055a80b4d02e490c52 











返回 应 用 id， 这 个 一 定 要 记 住 。 








访问 应 用 信息 ， 在 浏览 器 访问 : 


http://your-ip: 4096/api/dapps/get?id=7251e913394b521409d13310c50a938ad8a0a76e185a7d055a80b4d02e490c52。 





返回 信息 如 下 : 





{ 
success: true, 
dapp: { 
name: "helloworld", 
description: "ff", 


tags: "gg", 
link: "http://test.zip", 
type: 0, 


category: 1, 

icon: "http://test.lo0g.png", 

delegates: [ 
"0352486d87c928918638c8al3c7e4765f2c9fa075318bd680b8d95elcf1d616f", 
"cbb3671d343628fe03fba2f0139b783a7b86445f79ee55c99bf5bbe380e4fb46"， 
"2f23a9659e32032910b8e078c0c980c6cb7c3a052a235a59079bfd6d608ecc95"， 
"351c081c470f41620f4709b6b3ca3721dc920d4e528b27b8fa4d88635e53e128" 
"cbd808111a08081f7dc93aafd9fe26a70216e3f42d927660ab8d15b7bdf8998c" 


], 
unlockDelegates: 3, 
transactionId: "7251e913394b521409d13310c50a938ad8a0a76e185a7d055a80b4d02e490c52" 





表明 应 用 已 经 注册 成 功 。 


5. 部 署 应 用 到 节点 





拷贝 应 用 到 asch 目 录 : 





cp -r asch-dapp-test asch/chains/your-chain-name 





修改 受托 人 信息 ， 这 里 填写 上 面 生成 的 5 个 受托 人 的 主 密码 : 








root@i22ze7j0sus9exe3j2whbc2:~/asch# cat chains/your-chain-name/config.json 

1 "secrets": [ 
"olympic cushion neither ill like dutch sound attract panel nation road 
on5EEy gother joke draft crisp author mixed media wide target romance 
broceols arm wine festival suffer supply tourist brown jump plug base 
on non Virus video envelope defy fire price feel board together 
ve sudaen segment magnet concert leisure tank iron satisfy hint story 

Oor™ 











启 节 点 ， 访 问 DApp: 





./aschd restart 








此 时 访问 http://your-ip:4096/chains/your-chain-name/ 界 面 应 该 如 图 10-1 所 示 。 














Asch DApp Example 1 - hello world 


Please input master secret | Login 











10-1 应 用 登录 界面 





6.DApp 的 充值 和 转账 





























使 用 我 们 在 创建 DApp 时 填写 的 创 世 账 户 登 录 DApp， 可 以 看 到 我 们 发 行 的 内 置 资 产 ， 如 图 10-2 所 示 。 














Asch DApp Example 1 - hello world 


| Logout 


Account balances 


xcT I 00000000 











图 10-2 ”登录 之 后 显示 内 置 资产 














其 他 主 链 上 已 经 拥有 的 资产 也 可 以 充值 到 侧 链 里 。 主 要 有 两 种 方式 : 1) Web 钱 包 ; 2) asch-cli。 这 里 演示 一 下 如 何 使 用 asch-cli 向 DApp 充 值 : 





root@iZ2ze7j0sus9exe3j2whbc2z:~/asch# asch-cli deposit -~e "remove sand cushion 
hobby royal voice game pony bounce sketch enact blast" -d 7251e913394b52140 
9d13310c50a938ad8a0a76e185a7d055a80b4d02e490c52 -c XAS -a 10000000000 

665d16d12b0434481c87ca702631f51da477ef107cee45a35dab8ffe600dfb8e 





























充值 完成 后 ， 使 用 相同 的 主 密码 登录 DApp， 可 以 看 到 XAS 已 经 从 主 链 转移 到 了 DApp 内 部 ， 如 图 10-3 所 示 。 


Asch DApp Example 1 - hello world 











Account balances 


xAs oo 


AS 100 




















10-3 ”从 主 链 充值 到 侧 链 的 资产 


CE 


下 
避 


10.3 本章 总 绢 


本 章 从 三 个 方面 (业务 模型 、 经 济 模型 以 及 数据 模型 ) 阐述 了 如 何 设计 一 个 DApp。 读 者 可 以 参考 本 章 中 的 原则 ， 根 据 





现 逻 辑 很 有 帮助 。 在 本 章 的 最 后 ， 我 们 一 起 搭建 了 一 个 开发 环境 ， 这 是 进行 后 续 开 发 的 基础 。 


第 11 章 ”DApp 合 约 开发 与 接口 实现 








本 章 主要 介绍 CCTime 项 目的 合约 开发 、 接 口 








11.1 DApp 合 约 的 开发 


我 们 从 合约 代码 出 发 ， 以 点 带 面 介绍 合约 的 逻辑 ， 并 解释 Asch SDK 的 使 F 











以 及 前 端 开 发 ， 通 过 本 章 的 学 习 ， 读 者 可 以 知晓 一 个 DApp 开 发 的 详细 过 程 。 














方法 ， 尽 可 能 还 原 笔 者 在 编写 DApp 合 约 时 








临 的 问题 ， 


H 








质 。 这 样 给 编写 合约 的 过 程 中 遇 到 类 似 的 问题 ， 提 供 解 决 问题 的 思路 ， 希 望 读者 能 有 所 收获 。 




















合约 编写 其 实 就 是 写 入 接口 的 编写 ， 通 过 调 



































于 写 入 的 数据 一 定 要 慎之 又 慎 ， 确 保 数据 的 录入 是 符合 业务 需求 的 。 另 外 











所 以 一 个 完整 的 合约 需要 包含 如 下 要 素 : 


“ 数据 校 验 。 


“ 避免 重复 操作 。 
“ 数据 记录 。 


根据 业务 需求 中 提 到 的 功能 ， 





合约 对 数据 库 执行 写 入 操作 。 既 然 是 写 操作 ， 就 一 定 要 对 参数 进行 完整 校 验 ， 同 时 也 要 对 操作 权限 进行 认证 ， 











户 在 同一 种 合约 的 操作 ， 需 要 进行 限制 ， 避 免 寻 








11.1.1 创建 频道 (createChannel) 





























创建 频道 合 丝 

















同 理 ， 如 果 文 章 被 举报 三 次 ， 在 业务 逻辑 上 来 讲 ， 它 已 经 不 存在 了 ， 那 么 相应 的 数 拉 


于 创建 一 个 新 的 频道 ， 作 为 文章 的 容器 ， 也 会 汇总 显示 文 





数量 和 打 赏 数量， 汇总 之 所 以 设计 在 频道 的 数据 模型 上 ， 是 
表 中 的 articles 与 votes 更 新 放 在 了 每 一 次 的 相关 合约 之 中 ， 比 如 创建 文章 的 时 候 ， 我 同时 更 新 频道 的 文章 数量 ， 频 道 下 文章 获得 打 赏 之 后 ， 


居 也 需要 做 更 新 ， 更 新 频道 的 相关 统计 数 





E 复 的 数据 写 入 区 块 。 











自己 的 业务 场景 设计 符合 自己 需要 的 DApp， 理 解 项 




















录 结构 对 理解 项 


























和 当时 的 所 思 所 想 ， 也 会 抛 开 实际 的 问题 ， 去 思考 问题 的 原理 和 本 











为 数据 一 








区 块 就 无 法 篡改 ， 所 以 对 





需要 以 下 合约 : 创建 频道 、 更 新 频道 、 发 布 文章 、 打 赏 文 章 、 抽 奖 、 发 布 评论 、 点 赞 评论 、 举 报 、 结 算 抽 奖 、 领 取 奖 励 。 下 面 分 别 介绍 





因为 查询 汇总 可 能 会 有 未 知 数据 量 的 性 能 开销 ， 我 们 把 Channel 
也 会 增加 文章 的 投票 数量 。 


居 就 非常 有 必要 。 创 建 频道 的 代码 如 下 : 





// 创建 频道 合约 
createChannel: async function(name, url, desc) { 
app.validate('string', name, { length: 
app.validate('string', desc, { length: 
app.validate('string', url, { length: 
// 校 验 图 片 url 
if (!utils.validateImgUrl (ur1l)) { 
return 'Invalid image url' 
} 
// 数据 查询 
let exists = await app.model.Channel .exists({ name: name }) 
if (exists) { 
return 'Channel name already taken' 


} 

// 数据 锁定 
app.sdb.lock('channel.createQ@' + name ) 
// 


从 交易 对 象 中 取出 数据 


const { id, senderId, timestamp } = this.trs 


app.sdb.create('Channel', { 
id: app.autoID.increment ('channel max id'), 
tid: id -> 
creatorId: senderId, 
name, 
Urly 
desc, 
timestamp 


参数 描述 如 下 。 
“ name 为 频道 名 称 ， 保 持 唯一 。 
:ud 为 频道 图 片 的 网 络 地 址 。 
“ desc 为 频道 介绍 。 


1. 验 证 参数 








在 这 个 合约 里 ， 我 们 使 








仅仅 做 长 度 的 校 验 完全 不 够 ， 还 需要 校 验 参数 是 否 符合 规则 ， 比 如 url 需 要 有 合法 的 格式 ， 通 过 正则 校 验 其 是 否 合法 ， 代 码 里 使 


YA/ iTS 


{ minimum: 3，maximum: 50 } 
{ minimum: 50，maximum: 1024 } }) 
{ minimum: 10, maximum: 256 } }) 


}) 


app.validate (type，value，rules) 函数 校 验 传 入 的 字段 ， 指 定 校 验方 法 所 需要 的 规则 ， 对 名 称 、 描 述 、 


const urlReg = /(httplftplhttps) :\/\/[\w\-_]+(\.[\w\-_ 1+)+([\w\- 


\.,@?*=%8:/~\+#]*[\w\-\@?^=%E/~\+#])?/ 


const imgReg = /^https?:\/\/([\w]+\.)+[\w] {2,3} (\/[\w]+)+\. (jpgljpeg|png)+$/ 





























了 utils.validatelmgUrl 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/OEBPS/Text/... 


module.exports = { 
validateUrl: Url => urlReg.test (url)， 
validateImgUr1: url => imgReg.test (url), 
aliasSampler 


片 链 接 三 个 字段 进行 长 度 的 校 验 。 





属性 对 url 进 行 正则 校 验 : 


} 
Oi 


因为 区 块 链 分 布 式 存储 的 技术 还 不 完善 ，Asch 平 台 也 不 支持 大 文件 储存 ， 这 里 只 能 采取 其 他 的 方法 ， 所 有 涉及 图 片 的 存储 都 使 用 ul 的 形式 ， 在 前 端 页 面 中 泻 染 ， 在 用 户 使 用 的 过 程 中 差别 不 大 。 

















2 数据 排 重 














接着 合约 中 需要 对 频道 的 名 称 进行 排 重 检验 ， 这 里 使 用 了 对 数据 库 的 查询 接口 ，app.model.Channel.exists () 传 入 object 类 型 的 查询 条 件 ， 即 可 异步 返回 boolean 类 型 的 查询 结果 。 因 为 合约 的 方法 
前 声明 了 async 关 键 字 ， 则 可 以 直接 在 函数 前 使 用 await 采 用 同步 的 语法 获得 Promise 结 果 。 




































































校 验 成 功 之 后 ， 就 可 以 进行 写 入 数据 库 的 操作 了 ， 因 为 DApp 的 打包 时 间 是 10 秒 ， 所 以 数据 库 的 写 入 确认 需要 10 秒 之 后 生效 。 由 于 应 用 中 不 允许 出 现 相 同名 称 的 频道 ， 那 么 ， 如 何 避 免 在 这 个 区 块 时 间 
中 出 现 创建 同名 频道 的 合约 调用 ， 这 需要 使 用 app.sdb.lock 函 数 确保 创建 此 名 称 的 合约 在 同一 个 区 块 是 排他 的 ， 保 证 不 会 有 同名 的 频道 出 现在 数据 库 中 。 其 中 的 参数 为 字符 串 类 型 ， 作 为 标识 操作 的 key 来 储 
存 。 





















































这 里 简要 说 明 一 人 DApp 的 区 块 打 包 ， 核 心 的 原理 与 Asch 主 链 相同 一 一 受托 人 轮流 打包 区 块 ， 其 他 受托 人 验证 区 块 内 容 ， 如 果 应 用 的 数据 要 同步 写 入 区 块 ， 就 必须 有 一 套 冲 突 处 理 的 机 制 ， 假 设 一 位 有 
户 在 DApp 节 点 A 执 行 创建 频道 合约 ， 频 道 名 为 “测试 频道 ”， 与 此 同时 ， 另 一 位 用 户 在 DApp 节 点 B 执 行 了 创建 频道 合约 ， 频 道 名 也 为 “测试 频道 ”， 那 么 节点 A 与 节点 B 会 出 现 数据 冲突 ， 不 管 是 打包 区 块 
的 节点 还 是 验证 区 块 的 节点 ， 都 会 汇总 A 节 点 与 B 节 点 的 合约 并 执行 ， 遇 到 app.sdb.lock 之 后 验证 是 否 已 经 被 占用 ， 如 果 出 现 错误 回 滚 整个 区 块 。 



















































































Oi 


大 家 应 该 发 现 app.sdb.lock 是 一 个 代价 很 大 的 接口 ， 因 为 一 旦 被 触发 排他 操作 ， 就 要 回 滚 区 块 ， 所 以 建议 开发 者 们 慎 用 此 接口 ， 或 者 对 调用 接口 的 操作 用 手续 党 限 制 ， 在 CCTime 中 ， 创 建 频道 合约 的 调用 
手续 费 为 10000 个 Token。 


3.transaction 对 象 














this.trs 对 象 存储 了 合约 调用 的 信息 ， 并 作为 变量 被 绑 定 在 了 this 中 ， 其 结构 如 下 : 

















ER 
senderld 发 送 者 的 地 址 
timestamp 时 间 鹤 
senderPublicKey 发 送 者 的 公 钥 


4. 写 入 数据 














使 用 app.sdb.create 向 数据 库 写 入 数据 ， 第 一 个 参数 为 数据 模型 名 称 ， 第 二 个 参数 为 object 类 型 的 对 象 ，1D 生 成 接口 使 用 app.autolD.increment ('key') 生成 自 增长 的 ID 作为 数据 的 ID， 这 里 要 注意 数 
据 模 型 的 配置 ， 如 果 设 置 了 非 空 字段 ， 需 要 设置 初始 值 ， 否 则 会 保存 不 成 功 。 

































































11.1.2 ”更 新 频道 (updateChannel) 








其 实 根据 需求 没有 必要 添加 更 新 频道 的 接口 ， 但 是 考虑 到 频道 的 创建 通过 外 链 的 方式 加 载 
的 合约 也 尽 可 能 适用 于 频道 的 所 有 更 新 操作 。 


网 
网 


片 服务 器 可 能 会 失效 ， 于 是 提供 了 更 新 接口 。Asch 的 SDK 和 暂时 只 支持 更 新 一 个 字段 ， 更 新 频道 














片 ， 外 链 的 


























不 过 前 面 提 到 ， 不 允许 出 现 重 名 的 频道 ， 那 么 更 新 频道 名 称 的 功能 必须 要 做 限制 ， 以 免 出 现 数据 更 新 的 问题 。 更 新 频道 的 代码 如 下 : 











// 更 新 频道 信息 


updateChannel: async function(cid, field, value) { 


if (field === 'desc') { 
app.validate('string', value, { length: { minimum: 50, maximum: 1024 } }) 
} else if (field === "url') { 


app.validate('string', value, { length: { minimum: 10, maximum: 256 } }) 
if (!utils.validateImgUrl (value)) { 
return 'Invalid image url' 
} 
else { 
return ‘Channel ${field} not support update 
» 


let channel = await app.model.Channel.findone ({ 
condition: { 
id: cid; 
reports: { $lt: 3 } 


}) 
if (!channel) return 'Channel was baned or not exists' 
if (channel.creatorId !== this.trs.senderId) return 'Permission denied' 


let updateobj = { 
[field]: value 


} 
app.sdb.update('Channel', updateObj, { id: cid }) 


参数 描述 : cid 为 频道 ID field 更 新 字段 value 更 新 的 值 。 


1. 参 数 验 证 


























因为 更 新 频道 合约 是 一 个 稍微 抽象 的 合约 ， 支 持 传 入 要 修改 的 数据 库 属性 ， 根 据 属性 修改 对 应 的 属性 值 ， 我 们 要 对 不 同 的 属性 提供 不 同 的 校 验 规则 。 我 们 看 到 ， 合 约 只 允许 执行 ur 与 desc 两 种 字段 的 更 
新 操作 。 























另外 ， 需 对 传 入 的 cid 进 行 查询 ， 判 断 是 否 在 数据 库 中 存在 ， 避 免 一 些 错误 参数 调用 对 系统 造成 影响 。app.model.ChannelfindOne ({condition: object}) 用 来 查询 符合 要 求 的 单条 数据 ， 这 里 除了 
使 用 cid 作 为 过 滤 条 件 之 外 ， 还 添加 了 reports 数 量 作为 另 一 项 过 滤 条 件 ， 因 为 超过 举报 条 件 的 数据 在 系统 中 被 视 为 删除 ， 所 以 不 予 执行 更 新 操作 。 


















































2. 权 限 验证 











这 里 会 对 数据 所 有 权 进 行 验证 ， 验 证 的 判断 条 件 : 只 有 创建 频道 的 人 才 有 权限 修改 频道 的 信息 ， 那 么 其 他 调用 接口 的 人 会 返回 “Permission denied” ， 很 合理 。 
































updateObj 作 为 动态 的 更 新 数据 ， 拼 装 需要 更 新 的 对 象 ， 执 行 app.sdb.update (model-Name，updateObject，condition) 接口 更 新 。 








11.1.3 发布 文章 (postArticle) 


























发 布 文章 合约 是 调用 比较 频繁 的 合约 ， 这 里 要 添加 较为 严格 的 参数 判断 ， 涉 及 不 同 的 内 容 类 型 (如 新 闻 链 接 类 、 原 创 内 容 类 ) 和 不 同 结算 类 型 ， 也 要 对 类 型 的 数据 进行 相应 逻辑 处 理 。 发 布 文章 的 代码 
如 下 : 


// 提交 文章 
postArticle: async function (title, url, text, tags, cid, settleHeight) { 
if (lurl && !text) { 
return 'Should provide Url or text' 


} 
// 链接 或 内 容 只 能 选 其 一 
if (url && text) { 

return 'Both Url and text are not supported' 





下 
if (!settleHeight) return 'Should provide settleHeight' 
if (settleHeight <= this.block.height + constants.SETTLE BLOCK PERIOD) { 
77 设 轩 编外 周期 不能 少 圭一 星 则 
return "Settlement period between 24 hours and 1 month' 
} 
app.validate('string', tags, { length: { maximum: 256 } }) 
app.validate('string', title, { length: { minimum: 5, maximum: 256 } }) 
if (text) app.validate('string', text, { length: { minimum: 20, maximum: 4096 } }) 
if (url) { 
app.validate('string', url, { length: { minimum: 15, maximum: 256 } }) 
if (Iutils.validateUrl (url)) { 
return 'Invalid url' 


} 

// 验证 内 容 

if (text && text.length > 4096) { 
return 'Text too long' 


} 


if (loid) 1 
return 'Should provide channel id' 
} else { 


let exists = await app.model.Channel .exists({ id: cid, reports: { $1lt: 3 } }) 
if (lexists) { 
return 'Channel was baned or not exists' 

i 
人 
al) 
// 对 链接 进行 排 
app.sdb.1lock('postArticle@' + Url) 
let exists = await app.model .Article.exists({ url: url }) 
if (exists) { 

return 'Url already exists' 
} 
} 





二 


let data = { 
title: title, 
WL WL 
text: text || '', 
// tags: tags, 
id: app.autoID.increment ('article max id'), 
votes: 0, 0 
tid: thisetrssid: 
authorId: this.trs.senderId, 
timestamp: this.trs.timestamp, 
comments: 0, 
awardState: constants. AWARD STATE .NOT_AWARD YET, 
Cid: cids 
tags: tags, 
awardType: constants :AWARD TYPE.STAKE, 
settleHeight 
} 


await app.sdb.create('Article', data) 
app.sdb.increment ('Channel', { articles: 1 }, { id: cid }) 





参数 说 明 如 下 。 

' title: 标题 。 
“ud: 新 闻 链 接 。 
“text; 文章 内 容 。 
“ tags; 文章 标签。 
"cid: 频道 ID。 


“ settleHeight: 抽奖 模式 下 的 开奖 时 间 ， 按 照 区 块 高 度 计算 。 








参数 中 的 区 块 高 度 并 非 是 
@@; 访 


发 布 文章 的 类 型 分 为 新 闻 类 和 内 容 类 ， 数 据 通过 url 和 text 必 性 判断 ， 两 个 属性 只 允许 存在 一 个 ， 但 不 能 一 个 都 不 提供 。 




















链 的 区 块 高 度 ， 而 是 侧 链 自身 的 区 块 高 度 ， 这 里 的 区 块 生产 周期 也 是 10 秒 钟 。 


























另外 ， 为 了 鼓励 用 户 参与 打 赏 ， 发 布 文章 的 模式 默认 为 抽奖 模式 ， 需 要 验证 文章 的 高 度 参数 。 这 里 有 一 个 建议 : 对 一 些 关键 参数 的 验证 尽 可 能 放 在 合约 最 前 面 执行 ， 如 果 一 些 关 键 参 数 都 无 法 通过 校 
验 ， 那 么 也 就 没有 继续 执行 的 必要 了 。 





对 于 新 闻 类 文章 ， 我 们 对 url 参 数 也 做 了 排 重 验证 ， 这 里 不 去 过 滤 reports， 防 止 违 规 地 址 的 重复 创建 ， 增 加 审核 成 本 。 








因为 文章 是 依托 于 频道 创建 的 ， 所 以 这 里 也 不 能 忘记 判断 频道 的 状态 ， 在 每 次 创建 文章 的 时 候 需要 检查 频道 是 否 存 在 ， 如 果 不 存在 或 是 被 举报 了 ， 那 么 也 要 返回 错误 。 























涉及 一 些 数据 的 状态 ， 为 了 方便 开发 与 维护 ， 我 们 引入 了 常量 设置 ， 用 常量 的 命名 来 作为 状态 标识 ， 例 如 constants.AWARD STATE.NOT_AWARD _ YET 实际 值 是 1， 表 式 待 结算 。 常 量 设置 代 码 如 下 : 


算 ， 在 执行 的 结算 高 度 之 前 ， 所 有 的 打 赏 金额 不 会 立 | 


// 常量 配置 文件 
module .exports = { 
AWARD TYPE: { 
DEFAULT: 0, 
STAKE: 1 


}, 

AWARD STATE: { 
DEFAULT: 0, 
NOT_ AWARD YET: 1, 


AWARDED: 2 


}, 
SETTLE BLOCK PERIOD: 24 * 3600 / 10 

















之 前 提 到 了 一 些 数据 库 统计 字段 需要 在 关联 合约 创建 过 程 执行 更 新 ， 创 建文 章 之 后 ， 需 要 更 新 文章 所 属 频道 的 articles 属 性 。 这 里 用 到 了 


app.sdb.increment (modelName，updateObject，condition) 更 新 对 应 频道 的 文章 统计 数据 。 


























将 耗费 资源 的 操作 分 散 到 一 些小 的 操作 中 去 ， 因 为 文章 查询 如 果 遇 到 大 量 需 要 统计 的 频道 ， 会 增加 服务 器 的 查询 消耗 ， 影 响 整 个 应 用 的 使 用 体验 。 之 后 的 投票 和 领 奖 的 逻辑 设计 都 会 依照 此 原则 。 





11.1.4 打 赏 文章 (voteArticle) 








打 赏 文章 合约 的 逻辑 就 稍微 复杂 一 些 ， 因 为 有 两 种 不 同 的 更 新 策略 ， 所 以 需要 一 个 合约 两 种 执行 策略 。 默 认 模 式 使 用 及 时 结算 策略 ， 奖 励 分 为 两 部 分 : 受托 人 奖励 和 作者 奖励 。 抽 奖 模式 则 是 延 时 结 





即 结算 ， 而 是 统计 在 数据 库 中 ， 待 区 块 高 度 达到 文章 指定 高 度 时 ， 文 章 发 布 者 或 者 受托 人 执行 抽奖 结算 ， 执 行 “ 抽 奖 合约 ”。 根 据 打 赏 金额 算出 权重 















































再 抽取 一 名 幸运 参与 者 ， 打 赏 总 额 作为 奖励 分 为 三 部 分 给 出 受托 人 : 作者 和 中 奖 者 ， 将 结果 写 入 区 块 。 最 后 ， 得 奖 用 户 执行 “ 领 奖 合约 ”， 获 得 结算 奖励 。 














打 赏 文章 合约 包含 事实 结算 或 汇总 奖池 两 种 策略 逻辑 。 我 们 先 看 代码 : 








// 打 赏 文章 

voteArticle: async function(aid, amount) { 
if (!aid || !amount) return 'Invalid params' 
app.validate ('amount', amount) 


// 获取 用 户 余额 


let balance = app.balances.get (this.trs.senderId, VOTE CURRENCY) 


if (balance.lt(amount)) return 'Insufficient balance' 


let article = await app.model .Article.findone({ 
condition: { id: aid, reports: { $lt: 3 } } 


if (!article) return 'Article not found' 


let { awardType = constants.AWARD TYPE.DEFAULT, cid } = article 


let res 
// 切换 策略 
switch (awardType) { 
Case constants.AWARD TYPE.DEFAULT: 
res = voteDefaultSettle (article, amount, this.trs) 
break 
Case constants.AWARD TYPE .STAKE: 


res = await voteStakeSettle (article, amount, this.trs) 


break 
} 
if (!!res) return res 


let bAmount = bignum(amount) 
let increment = Number( 
bAmount 
.div (VOTE UNIT) 
.floor() 
.tostring() 
9 


app.sdb.increment ('Article', { votes: increment }, { id: 
app.sdb.increment ('Channel', { votes: increment }, { id: 


aid }) 
cid }) 





参数 说 明 : 
aid 为 文章 ID。 


` amount 为 打 赏 金额 。 


打 赏 合约 在 校 验 完 参数 之 后 ， 需 要 进行 余额 校 验 ， 如 果 账 户 没 有 余额 ， 则 返回 错误 ，app.balances.get (address，VOTE_ CURRENCY) 这 个 接口 返 





渤 4 
函数 判断 当前 账户 余额 是 否 足够 执行 打 赏 合约 。 











回 ] 











了 一 个 bignumber 对 象 ， 可 以 通过 bignumber.lt 





我 们 都 知道 JavaScript 浮 点 数 计算 的 精度 问题 ， 我 们 基于 第 三 方 开 源 库 bignum 进 行 封 装 ， 相 对 资产 数额 的 保存 也 是 按照 包含 精度 信息 的 “大 数 ”储存 ， 例 如 ， 一 项 资产 的 精度 为 8， 发 行 总 量 为 


下 面 介绍 编写 不 同 的 打 赏 策略 。 











21000000， 那 么 它 在 系统 中 存储 的 形式 为 '2100000000000000'"， 所 以 在 开发 的 时 候 需 要 注意 带 上 精度 信息 ， 系 统 中 所 有 关于 数额 的 操作 都 按 以 上 的 规则 处 理 。 











投票 操作 会 判断 文章 的 奖励 类 型 ， 如 果 是 默认 模式 调用 voteDefaultSettle; 抽奖 模式 调用 votestakeSettle。 这 里 纯粹 是 为 了 维护 方便 ， 把 代码 逻辑 通过 函数 拆 分 ， 另 一 个 考虑 是 为 后 续 新 的 分 配 策略 预 








留 扩展 ， 不 管 awardType 是 多 少 ， 都 可 以 分 发 到 新 的 代码 逻辑 处 理 。 下 | 

















面 看 一 下 不 同 逻 辑 的 代码 如 何 实现 : 











// 默认 分 配 逻 辑 -也 是 实时 结算 逻辑 

Const voteDefaultSettle = (article, amount, trs) => { 
let bamount = bignum(amount) 
if (bAmount.1t (VOTE UNIT) ) return "Rmount too small' 
amount = bamount .toString () 
const { senderId, id, timestamp } = trs 


let authorReward = bAmount 
.mul (0.5) 
.floor () 
.tostring() 
let extraFee = bAmount.sub (authorReward) .toString () 


app.balances.decrease (senderId, VOTE CURRENCY, amount) 


app.balances.increase (article. authorIqd, VOTE _CURRENCY， authorReward) 


app.feePool.aqddqd (VOTE CURRENCY, extraFee) 
app.sdb.create('Vote', { 
id: app.autoID.increment ('vote max id'), 
tid: id; 2 
aid: article.id, 
voterId: senderId, 
timestamp, 
amount: amount, 
type: 0 





以 上 代码 逻辑 是 处 理 默认 即时 结算 模式 的 奖励 ，VOTE_UNIT 是 作为 最 小 打 赏 额度 设 定 ， 规 定 打 赏 额度 不 能 低 
bignum 库 进行 计算 ， 默 认 结 算 方式 是 受托 人 获得 打 赏 金额 的 50%， 剩 余 的 50% 结 算 给 作者 。 














问题 ， 也 会 使 








app.balances.decrease 上 








我 们 留意 一 下 费 





接口 














再 来 看 抽奖 模式 的 


// 抽奖 模式 投票 -汇总 奖池 


合约 代码 ， 这 里 包含 了 激励 














来 减少 打 赏 者 的 余额 ，app.ba 





























抽奖 逻辑 














区 块 ， 受 托 人 会 平分 手续 费 。 


户 和 随机 抽奖 的 业务 逻辑 : 


const voteStakeSettle = async (article, amount, trs) => { 
let bAmount = bignum(amount) 


if 


amount = bAmount. toString 
const { senderId, id, timestamp } = trs 


const aid = article 


id 


(bamount .1t (VOTE UNIT) ) return ‘Amount too small' 


ances.increase 增 加 作者 的 余额 (50% 打 赏 额 ) ， 再 通过 app.feePool.add (VOTE_CURRENCY，extraFee) 将 受托 人 奖励 放 入 费 上 








某 个 








定 值 ， 金 额 设 定 依然 使 有 








bignum 格 式 的 数据 。 另 外 ， 余 额 计算 为 了 避免 出 现 精度 














池 。 














app.balances， 这 里 是 可 以 通过 指定 地 址 、 币 种 名 称 与 数额 来 完成 余额 操作 的 ， 那 么 我 们 就 可 以 指定 不 同 的 资产 ， 实 现 多 资产 转账 。 同 理 app.feePool.add 函 数 也 可 以 放 入 不 同 
类 型 的 资产 ， 它 直接 进行 了 打 赏 额 分 发 ， 最 后 把 投票 记录 写 入 


const condition = { aid: aid, voterId: senderId, type: constants.AWARD TYPE.STAKE } 


// 防止 在 一 个 区 块 用 户 对 文章 内 重复 投票 
app.sdb.lock('cctime.vote@' + aid + senderId) 
let vote = await app.model .Vote.findone({ condition: condition }) 
app.balances.decrease (senderId, VOTE_ CURRENCY, amount) 


let voteId 
if (vote) { 
VoteId = vote.id 





app.sdb.increment ('Vote', { amount: amount }, condition) 


else { 


voteId = app.autoID.increment ('vote max id') 
app.sdb.create('Vote', { 


id: voteId, 
tid: id; 
aid, 


awardState: constants. AWARD STATE .NOT_AWARD YET, 
voterId: senderId, 


timestamp, 
amount: amount, 
type: constants 


D) 


¢ 
// 添加 抽奖 模式 的 打 赏 ii 
app.sdb.create ('Bid 


-AWARD _TYPE. STAKE 


己 录 


Te 


id: app.autoID.increment ('bid max id'), 


tid: idy 
vid: voteId, 
aid, 


voterId: senderId, 


timestamp, 
amount: amount 


我 们 先 从 实际 场景 分 析 一 下 ， 假 设 















































户 参与 了 抽奖 模式 的 打 赏 ， 那 么 他 也 期 待 抽奖 周期 结束 






















































































后 有 几率 获得 超出 打 赏 额 的 回报 。 这 里 会 有 一 些 衍生 的 问题 出 现 : 第 一 个 问题 ， 如 何 保证 抽奖 算法 随机 ; 第 

















层面 考虑 ， 我 们 当然 希望 














户 多 多 参与 打 赏 ， 鼓 励 更 多 的 优质 内 容 输出 ， 这 样 限制 打 赏 次 数 就 




















二 个 问题 ， 用 户 能 否 重复 的 打 赏 ;第 三 个 问题 ， 开 奖 之 后 用 户 的 打 赏 是 否 会 有 奖励 。 
第 一 个 问题 从 算法 层面 的 选 型 来 看 ， 抽 奖 就 需要 有 一 个 完全 随机 的 算法 实现 。 第 二 个 问题 ， 从 整个 产品 的 
不 符合 产品 预期 ， 所 以 应 当 人 允许 用 户 重复 打 赏 。 
既然 允许 用 户 重 复 打 赏 ， 就 需要 考虑 一 个 新 问题 一 一 重复 打 赏 和 
面 看 ， 并 没有 必要 ， 因 为 抽奖 是 为 了 促进 
户 继续 打 赏 (当然 也 不 禁止 ) ， 而 是 希望 能 够 更 关注 于 新 发 布 的 文章 。 所 以 在 抽奖 周期 结束 之 后 ， 文 章 结算 模式 






































从 另 一 个 层面 去 促进 





11.1.5 ”抽奖 设计 


内 容 创 作者 持续 产 出 新 的 内 容 。 上 


站 纯 的 只 打 赏 一 次 是 否 享受 相同 的 中 奖 概率 。 这 也 是 算法 问题 。 第 三 个 问题 ， 开 奖 结束 之 
户 参与 打 赏 ， 也 想 鼓励 优质 内 容 ，CCTime 的 排序 算法 是 按照 时 间 与 打 赏 数额 为 依据 ， 时 间 在 热度 算法 中 权重 更 高 。 那 么 过 了 一 定 周期 的 文章 尽 可 能 地 不 鼓励 





后 是 否 可 以 继续 进行 新 的 抽奖 周期 ， 从 产品 


三 
去 



























































在 设计 之 初 ， 考 虑 到 使 





随机 


























元 


面 代码 就 是 


平均 权重 的 方式 进行 抽奖 ， 但 是 这 样 对 重 








于 解决 这 三 个 问题 的 。 





自动 切换 为 默认 模式 ， 这 样 作者 依然 会 有 收益 ， 只 不 过 热度 不 会 有 抽奖 模式 下 那么 高 ， 也 能 







































































户 的 打 赏 额 来 决定 抽奖 的 概率 ， 这 样 既 可 以 提高 优质 























到 了 











他 用 户 相同 的 获奖 概率 ， 那 就 不 太 可 能 再 次 打 赏 。 
所 以 累加 用 户 的 打 赏 权重 ,根据 
法 超越 打 赏 额 的 情况 。 那 么 算法 不 仅 





得 机 ， 而 且 要 在 一 定 的 权重 下 随机 ， 于 是 使 























户 并 不 公平 ， 而 且 也 起 不 到 激励 打 赏 行为 的 作 户 只 需要 对 文章 打 赏 一 小 笔 最 小 额 就 可 以 得 到 ;与 其 











， 如 果 一 个 
































内 容 的 打 赏 收入 ， 又 可 以 促使 用 户 为 了 提高 赏 金 无 








自己 获奖 概率 提高 打 赏 金额 或 次 数 。 也 能 避免 参与 人 数 过 少 ， 





“装备 掉 落 ”的 算法 。 














假设 你 在 一 个 装 满 不 同 种 类 奖品 的 不 透明 盒子 里 取出 一 个 作为 奖品 ， 你 取出 什么 样 的 奖品 概率 最 高 呢 ? 当然 是 同 种 类 数量 最 多 的 奖品 。 所 以 “装备 掉 落 ”就 是 固定 了 装备 的 种 类 (在 合约 里 代表 不 同 的 


打 赏 参与 者 ) ， 但 每 个 种 类 的 数量 (在 合约 里 是 





























户 


当然 ， 如 果 














不 参 


与 打 赏 ， 抽 奖 模式 





元 


也 就 起 不 到 任何 鼓励 作用 。 


























户 打 赏 的 Token 数 量 ) 决定 了 装备 的 掉 落 概率 。 


合约 里 我 们 把 Vote 数 据 模型 中 type 设 为 1 (抽奖 模式 的 打 赏 作为 一 条 更 新 记录 来 维护 ， 也 就 是 说 ， 在 抽奖 模式 中 如 果 用 户 之 前 在 此 文章 中 没有 打 赏 记录 ， 那 么 新 建 一 条 记录 ; 如果 之 前 有 同类 型 的 打 
赏 记录 ， 则 累加 之 前 的 打 赏 金额 。 当 文章 抽奖 结束 ， 状 态 转变 为 默认 模式 ， 执 行 默认 的 模式 。 








另外 





回 到 合约 代码 ， 先 校 验 参数 和 账 





因为 抽奖 模式 中 只 更 新 Vote 记 录 ， 我 们 又 引入 了 另外 一 个 Bid 模 型 ， 作 为 保存 抽奖 模式 参与 记录 。 
































app.balances.decrease 上 





因为 牵涉 到 金额 的 变动 ， 


来 扣除 

















也 需要 对 

















11.1.6 发布 评论 (postComment) 


发 布 评论 可 以 针对 文章 也 可 以 针对 评论 进行 回复 ， 如 果 大 家 掌握 了 之 前 的 合约 内 容 ， 应 该 能 够 


户 余 额 是 否 合法 ， 通 过 打 赏 类 型 和 


户 的 打 赏 进行 锁 限制 ， 避 免 























应 














打 赏 ， 这 里 








户 地 址 判断 当前 文章 下 是 否 有 重复 的 打 赏 记录 ， 如 果 没 有 ， 添 加 一 条 新 的 打 赏 记录 ;否则 更 新 
户 打 赏 额 ， 打 赏 记录 的 累计 金额 未 来 在 抽奖 结算 的 时 候 作为 奖池 汇总 使 用 。 




















户 原 有 的 抽奖 记录 ， 累 计 金 额 。 


























为 余额 的 变动 没有 经 过 











区 块 确认 ， 如 果 








在 一 个 区 





周期 之 内 多 次 打 赏 额 超出 了 余额 ， 会 导致 交易 失败 。 








自己 写 出 发 布 评论 的 合约 了 ， 代 码 如 下 所 示 : 





// 发 布 评论 


postComment: async function(aid, pid, content) { 


if (!laid) { 


return 'Invalid article id'" 
if (!content) { 
return 'Invalid content' 
} 
if (content.length > 4096) { 
return 'Content size too long’ 


} 
if (pid) { 
let exists = await app.model .Comment .exists({ id: pid }) 
if (!exists) { 
return 'Reply comment not exists' 
} 
} 
app.sdb.create('Comment', { 
id: app.autoID.increment ('comment max id'), 
aid: aid, 
pid: pid, 
content: content, 
rewards: 0, 
tid: this,.trscid, 
authorId: this.trs.senderId 
}) 
app.sdb.increment ('Article', { comments: 1 }, { id: aid }) 





参数 说 明 : 
“aid 为 文章 ID。 


“ pid 为 评论 ID content 评 论 内 容 。 








这 里 通过 pid 参 数 判断 是 否 为 评论 回复 ， 另 外 对 文章 统计 进行 更 新 ， 细 节 不 再 熬 述 。 


11.1.7 点 赞 评论 (likeComment) 








点 赞 评论 合约 完成 的 是 一 个 转账 流程 ， 用 户 对 文章 的 评论 表 式 赞同 ， 可 以 通过 点 赞 形式 给 评论 者 奖励 ， 代 码 如 下 所 示 : 




















// 点 赞 评论 
likeComment: async function (cid，amount) { 
if (!cid || !amount) return 'Invalid params' 


app.validate ('amount', amount) 


let balance = app.balances.get (this.trs.senderId, COMMENT REWARD CURRENCY) 
if (balance.1lt (amount)) return 'Insufficient balance' 


let bamount = bignum(amount) 
if (bAmount.1t (COMMENT REWARD UNIT)) return ‘Amount too small' 


let comment = await app.model.Comment.findone ({ 
condition: { id: cid } 
}) 


if (!comment) return 'Comment not found' 
app.balances.transfer (COMMENT_ REWARD CURRENCY, amount, this.trs.senderId, comment.authorId) 


let increment = Number( 
bamount 
.div (COMMENT REWARD UNIT) 
.floor () 本 2 
‘toString () 
) 


app.sdb.increment ('Comment', { rewards: increment }, { id: cid }) 





参数 说 明 : 


“cid 为 文章 ID。 


:amount 为 评论 ID。 





app.balances.transfer (currency，amount，sender，receiver) 接口 实现 了 账户 之 间 转 账 ， 通 过 bignum 保 证 数额 计算 结果 。 











11.1.8 举报 (report) 





举报 合约 做 了 一 层 抽象 ， 把 对 频道 、 文 章 、 评 论 的 举报 功能 在 一 个 合约 实现 ， 并 完成 统计 数据 更 新 ， 代 码 如 下 所 示 : 





// 举报 
report: async function(topic, value) { 
if (!topic || !value) return 'Invalid params' 


// 通过 topic 判断 举报 的 数据 类 型 
topic = Number (topic) 
if ([1, 2, 3] .indexOf (topic) === -1) return 'Invalid topic' 


if (app.meta.delegates.indexOf (this.trs.senderPublicKey) === -1) return 
"Permission denied' 


let reporter = this.trs.senderId 
app.sdb.lock('cctime.report@' + value) 
let exists = await app.model.Report .exists({ 
reporter: reporter, 
topic: topic, 
value: value 
}) 
if (exists) return 'Already reported' 


switch (topic) { 


Case 1: 
model = 'Article' 
break 
Case 2; 
model = 'Comment' 
break 
case 3; 
model = "Channel' 
break 
} 
let data = await app.model [model] .findone ({ condition: { id: value } }) 
// 对 将 要 被 标记 为 删除 的 数据 进行 统计 处 理 
if (data.reports == 2) { 


decreaseCount (model, data) 
} 


app.sdb.increment (model, { reports: 1 }, { id: value }) 
app.sdb.create('Report', { 

reporter: reporter, 

topic: topic, 

value: value 


}) 





参数 说 明 如 下 。 
“ topic: 举报 类 型 ，1 为 文章 ，2 为 评论 ，3 为 频道 。 


“ Value; 数据 ID。 




















注意 app.meta.delegates 属 性 ， 我 们 通过 这 个 属性 能 够 获得 DApp 的 受托 人 公 钥 列表 ， 可 以 通过 对 比 合约 调用 者 的 公 铜 ， 验 证 他 的 身份 是 否 为 受托 人 。 之 前 在 业务 设计 中 提 到 ， 受 托 人 有 权限 同时 也 有 
义务 对 违规 内 容 做 清理 ， 那 么 举报 合约 应 该 对 受托 人 的 身份 进行 验证 。 











另外 ，app.modelImodel].findOne 也 实现 了 动态 的 模型 查询 ,合约 中 对 即将 标记 为 违规 的 内 容 做 统计 更 新 ， 把 统计 人 逻辑 拆 分 为 decreaseCount 函 数 ， 更 新 统计 字段 ， 代 码 如 下 所 示 : 





// 更 新 被 删除 的 统计 字段 
Const decreaseCount = (model, data) => { 
if (model == 'Article') { 
let cid = data.cid 
let votes = data.votes 
app.sdb.increment ('Channel', { articles: -1 }, { id: cid }) 
app.sdb.increment ('Channel', { votes: 0 - votes }, { id: cid }) 
: 
if (model == 'Comment') { 
let aid = data.aid 
app.sdb.increment ('Article', { comments: -1 }, { id: aid }) 
} 
} 





合约 只 需要 对 应 更 新 相关 联 的 统计 字段 即 可 。 


11.1.9 ”结算 抽奖 (calculatePrize) 








结算 抽奖 合约 调用 条 件 是 区 块 到 达 指 定 高 度 ， 并 且 合约 执行 人 是 文章 作者 或 受托 人 。 这 里 实现 了 抽奖 算法 ， 并 执行 奖励 结算 ， 代 码 如 下 所 示 : 














// 开奖 合约 ， 计 算 奖励 
calculatePrize: async function(aid) { 
if (!aid) return 'Invalid article id' 
let article = await app.model1.Article.findqone ({ 
condition: { 
id: aid, 
awardState: constants.AWARD STATE.NOT AWARD YET, 
awardType: constants.AWARD TYPE.STAKE, 
settleHeight: { $1t: this.block.height } 
} 





}) 

if (!article) return 'Article not exists or settle time not arrived' 

const isNotDelegate = app.meta.delegates.indexOf (this.trs. 
senderPublickey) 一 

const isNotAuthor = this.trs.senderId !== article.authorId 

// 判断 权限 


if (isNotDelegate && isNotAuthor) return 'Permission denied' 





let votes = await app.model .Vote.findAll ({ 
condition: { aid: aid }, 
fields: ['amount', 'id'] 


}) 
// 如 果 没 有 投票 记录 ， 则 直接 结束 
if (votes.length == 0) { 
app.sdb.update('Article', { awardState: constants.AWARD STATE .AWARDED 
ya { Ld: alg } 
return 'Vote not exists ' 
} else { 
let voteIdArr = [] 
let probArr = [] 
let votesSum = bignum(0) 
// 汇总 打 赏 金额 
Votes.forEach(v => { 
votesSum = votesSum.add (v.amount) 
}) 
// 计算 作者 奖励 
let authorReward = votesSum 
.mul (0.3) 
.floor () 
.tostring () 


// 计算 受托 人 奖励 

let extraFee = votesSum 
.mul (0.1) 

.floor () 

.tostring() 


// 计算 奖金 

let stakePrize = votesSum 
.Sub (authorReward) 

.Sub (extraFee) 

.tostring() 


// 统计 打 赏 人 员 并 算出 每 人 的 权重 
votes.forEach (vote => { 
voteIdArr .push (vote.id) 
probArr .Push ( 
Number ( 
bignum(vote.amount) 
.div (votesSum) 
.tostring() 








几 


) 
) 


}) 

// 通过 抽奖 算法 获取 抽奖 用 户 的 编号 

let sampleFun = utils.aliasSampler (probArr) 
let index = sampleFun() 


let winnerId = voteIdArr [index] 
app.sdb.update('Vote', { settleAmount: stakePrize }, { id: winnerId }) 
app.sdb.update( 

'Vote', 

{ awardState: constants.AWARD STATE.NOT AWARD YET }, 

{ id: winnerId } 加 


) 

// 分 发 奖励 

app.balances.increase (article.authorId, VOTE CURRENCY, authorReward) 

app. feePool .add (VOTE_ CURRENCY, extraFee) 

app.sdb.update('Article', { awardState: constants.AWARD STATE .AWARDED 
re tT id: aild 


app.sdb.update ('Article', { awardType: constants.AWARD TYPE.DEFAULT 
}, { id: aid }) 





参数 说 明 : aid 为 文章 |D。 






























































首先 查询 文章 信息 ， 我 们 用 三 个 参数 去 过 滤 文章 数据 : 文章 类 型 、 结 算 状 态 与 区 块 高 度 ， 过 滤 条 件 为 文章 类 型 为 抽奖 模式 ， 结 算 状 态 为 待 结算 ， 结 算 的 区 块 高 度 小 于 当前 区 块 高 度 的 条 件 过 滤 文 章 。 这 
里 使 用 this.block.height 来 获取 当前 区 块 的 高 度 ， 侧 链 中 每 次 创建 新 区 块 的 时 候 会 更 新 高 度 。 


























isNotAuthor 和 isNotDelegate 作 为 判断 权限 的 依据 ， 决 定 合约 执行 人 是 否 能 够 执行 结算 。 整 体 的 逻辑 是 将 当前 文章 下 属于 抽奖 类 型 的 投票 记录 全 部 查询 出 来 ， 之 前 提 到 抽奖 模式 的 打 赏 金额 一 个 人 可 以 
累加 金额 多 次 ， 最 终 的 打 赏 金额 通过 汇总 累加 ， 根 据 每 个 人 的 打 赏 额 算出 比例 ， 即 可 得 出 每 个 人 的 权重 。 




















将 打 赏 总 额 分 为 三 份 ， 现 在 的 策略 是 受托 人 奖励 10%， 作 者 奖励 30%， 剩 余 的 作为 奖金 返还 给 中 奖 者 。 


抽奖 算法 : utils.aliasSampler (probArr) 方法 中 的 参数 是 投票 者 投票 额 占 总 额 的 比重 ， 这 个 顺序 与 voteldArr 中 保存 的 Voterld 索 引 相同 ， 而 aliasSampler 返 回 的 索引 就 是 中 奖 者 的 索引 ， 通 过 索引 从 
voteldArr 中 取 到 对 应 索引 的 打 赏 者 的 ID， 更 新 打 赏 数据 与 状态 。 之 前 在 打 赏 合约 的 抽奖 设计 中 提 到 需要 一 种 随机 但 保证 权重 的 算法 ， 游 戏 中 就 有 这 样 的 算法 ， 在 游戏 服务 器 中 设置 各 种 宝物 的 掉 落 概率 ， 那 
么 系统 每 次 结算 的 时 候 都 按照 这 个 概率 随机 抽样 掉 落 宝物 ， 这 样 就 符合 随机 且 保 证 权 量 的 目标 。 

















掉 宝 算法 不 在 这 里 详 述 ， 感 兴趣 的 读者 可 以 去 代码 样 例 库 中 学 习 。 (https://blog.csdn.net/sky_zhe/article/details/10051967 这 篇 文章 也 给 出 了 比较 详细 的 解释 。) 


11.1.10 ”领取 奖励 (getReward) 


























领取 奖励 需要 获奖 人 手动 发 起 ， 也 是 考虑 到 服务 器 性 能 和 区 块 链 应 用 的 特性 ， 将 已 知 的 性 能 压力 分 散 到 可 控 的 单项 合约 调用 之 中 ， 那 些 需要 批量 执行 或 者 自动 触发 的 操作 尽量 避免 ， 尽 量 采 用 用 户主 动 
发 起 的 方式 实现 。 



































代码 如 下 所 示 : 





// 领取 奖励 
getReward: async function(vid) { 
if (lvid) { 
return "Invalid Param' 


let vote = await app.model.Vote.findone ({ 
condition: { 
id: vid, 
awardState: constants. AWARD STATE .NOT_AWARD YET, 
type: constants.AWARD TYPE.STAKE 
} 


if (!Ivote) return '‘'Vote not exists' 

if (vote.voterId !== this.trs.senderId) return 'Permission denied' 

if (vote.settleAmount == 0) return 'No reward' 

// 获取 结算 金额 

const { settleAmount } = vote 

app.balances.increase (this.trs.senderId, VOTE CURRENCY, 
bignum(settleAmount) .上 toString ()) 

app.sdb.update ('Vote',{ awardState: constants.AWARD STATE.AWARDED}, {id: 
vid}) 

app.sdb.update ('Article',{ awardState: constants.AWARD STATE.AWARDED },{ 
id: aid} ) 

} 





参数 说 明 : vid 为 投票 ID。 

















领 交合 约 首先 要 对 合约 调用 者 的 身份 进行 验证 ， 通 过 投票 的 ID 和 结算 状态 对 打 赏 的 记录 进行 过 滞 ， 然 后 通过 Vote 中 的 比 对 合约 检查 调用 者 是 否 为 打 赏 者 本 人 。 
@ia 示 


去 中 心 应 用 对 权限 的 验证 是 分 散在 各 个 合约 中 实现 的 ， 因 为 所 有 的 登录 和 身份 都 是 不 会 在 后 端 服务 器 或 前 端 保存 ， 我 们 也 可 以 把 CCTime 作 为 一 个 前 后 端 分 离 的 服务 来 看 ， 只 是 这 个 账户 权限 需要 通过 公 
铀 或 地 址 来 验证 。 





























合约 之 后 的 代码 相信 读者 都 能 够 看 明白 。 受 限于 目前 的 实现 ， 使 用 app.sdb.update 接 口 ， 只 能 一 次 调用 更 新 一 个 属性 ， 未 来 Asch 会 将 SDK 升 级 到 以 面向 对 象 的 方式 操作 数据 库 接口 。 
































11.2 ”DApp 接 口 的 实现 








这 一 部 分 我 们 来 编写 DApp 的 服务 接口 ， 以 RESTful 形 式 ， 对 外 提供 数据 查询 服务 ， 涉 及 数据 组 织 和 多 次 查询 等 操作 ， 以 接口 形式 对 外 提供 服务 。 






































接口 在 DApp 中 属于 读 操作 ， 因 为 区 块 生成 时 间 的 限制 ， 应 用 打包 之 后 才 会 更 新 数据 ， 那 么 我 们 的 接口 查询 也 只 能 每 10 秒 更 新 一 次 ， 所 以 查询 的 结果 可 以 通过 之 前 提 到 的 IntervalCache 进 行 缓存 ， 设 置 
好 缓存 空间 的 时 效 周期 即 可 。 在 访问 量 较 大 的 情况 下 ，IntervalCache 可 以 减缓 服务 器 压力 。 














那么 查询 缓存 是 如 何 实现 的 呢 ， 我 们 来 看 下 面 的 缓存 实现 的 代码 : 








// 查询 缓存 lib/Interval-cache.js 


class IntervalCache { 

// 构造 函数 ， 设 置 数据 重 置 周期 

constructor (interval) { 
if (!Number.isInteger (interval)) throw new Error('Invalid interval') 
this.interval = interval 
this.container = new Map 
setInterval (() => { 

this.container.clear () 

}, interval) 


: 

// 判断 是 否 有 缓存 

has (key) { 
return this.container.has (key) 

上 

// 设置 缓存 

set (key, value) { 
this.container.set (key, value) 


} 
// 获取 缓存 


get (key) { 
return this.container.get (key) 


} 
} 


module .exports = IntervalCache 








代码 只 是 维护 了 一 个 map 结 构 ， 通 过 构造 函数 初始 化 一 个 清空 缓存 的 周期 ， 固 定 清空 container 的 内 容 。 在 init 文 件 中 ， 调 用 app.custom.cache=new IntervalCache (10*1000) 把 缓存 文件 赋值 给 


app.custom.cache 交 给 系统 处 理 。 





























以 上 代码 只 有 对 缓存 的 操作 接口 ， 具 体 的 缓存 使 用 是 在 每 个 接口 进行 查询 之 前 和 查询 之 后 ， 进 行 获取 和 设置 ， 通 过 不 同 的 key 作 为 索引 ， 维 护 在 map 中 。 相 当 于 把 map 维 护 的 接口 分 散 到 各 个 对 外 提供 





oD 








的 读 服务 中 。 下 面 我 们 来 看 看 接口 都 做 了 什么 。 























为 接口 都 是 GET 类 请 求 ， 为 了 介绍 方便 ， 我 们 按 模型 分 别 说 明 。 这 里 主要 有 频道 、 文 章 和 投票 三 个 接口 。 

















11.2.1 ”频道 接口 


频道 查询 需要 两 个 接口 : 支持 分 页 的 频道 列表 查询 cha 





1. 获 取 频 道 列表 


代码 如 下 所 示 : 


nnels 和 获取 频道 详情 查询 channels/: id， 我 们 先 从 频道 列表 查询 接口 为 例 ， 介 绍 查询 接口 编写 的 细节 。 














// channels 
app.route.get ('/channels', async req => { 
let query = req.query 
let sort = {} 
// 排序 参数 校 验 
if (req.query && query.sortBy) { 
let sortInfo = query.sortBy.split(':') 


EB 
sortInfo.length !== 2 || 
['timestamp', 'articles', ‘votes'].indexOf (sortInfo[0]) ==—= -1 || 
['asc', 'desc'] .indexOf (sortInfo[1]) === -1 


throw new Error('Invalid sort params') 


} 


Sort [sortInfo[0]] = sortInfo[1] === 'asc' ? 


. 
// 参数 解析 


二 


let queryArr = ['channels', query.sortBy, query.limit, query.offset] 
if (query.creatorId) queryArr.push (query.creatorId) 


if (query.tid) queryArr.push (query.tid) 

let key = queryArr.join('_') 

// 缓存 查询 

if (app.custom.cache.has (key)) { 
return app.custom.cache.get (key) 


于 
// 拼接 查询 规则 
let condition = [{ reports: { $1lt: 3 } }] 


if (query.creatorId) condition.push({ creatorId: query.creatorId }) 
if (query.tid) condition.push({ tid: query.tid }) 
let count = await app.model.Channel .count (condition) 


// 执行 查询 


let channels = await app.model.Channel .findAll ({ 


condition: condition, 
limit: query.limit || 50, 
offset: query.offset || 0, 
sort: sort 


和 


let result = { count, channels } 
// 设置 缓存 结果 
app.custom.cache.set (key, result) 
return result 


从 代码 来 看 ， 我 们 梳理 一 下 接口 的 查询 流程 : 





1) 参数 校 验 。 
2) 参数 解析 。 


3) 查询 缓存 。 





4) 拼接 查询 规则 检索 数据 库 。 





5) 设置 缓存 结果 。 























除了 使 用 了 app 中 注入 的 函数 和 方法 ， 这 些 代码 逻辑 与 一 个 普通 的 数据 查询 接口 没有 任何 区 别 ，router 也 是 遵照 了 express 形 式 的 接口 方法 定义 。 




















参数 校 验 中 ， 对 sort 参 数 的 格式 与 字段 校 验 ， 需 包含 [timestamp'，'articles'，'votes'] 三 种 排序 类 型 ，['asc'，'desc'] 两 种 类 型 ， 同 时 支持 对 creatorld 与 tid 的 条 件 过 渡 。 








条 件 拼接 完毕 后 ， 使 用 app.model.Channel.findAlI 函 
作为 排序 字段 传 入 查询 中 ， 返 回 相应 的 结果 。 








app.custom.cache.has (key) 在 数据 进行 查询 之 前 ， 





数 进行 数据 查询 ， 参 数 为 对 象 ， 其 中 condition 作 为 查询 条 件 对 象 ，limit 为 每 次 查询 条 数 ，offset 为 偏离 值 ， 两 个 参数 实现 了 查询 分 页 功能 。sort 














判断 缓存 中 是 否 已 经 包含 了 对 应 的 查询 key， 如 果 包 含 ， 则 直接 返回 之 前 查询 返回 的 结果 。 在 这 里 就 要 规范 好 缓存 中 索引 规则 ， 避 免 出 现 不 同 查 











询 出 现 相同 缓存 的 问题 。 因 为 查询 接口 需要 支持 多 参数 或 








a 参数， 那么 对 于 缓存 对 象 索 引 的 维护 ， 就 需要 考虑 参数 数量 不 固定 的 情况 ， 最 终 我 们 看 到 了 let key=queryArrjoin('') 这 段 代 码 ,维护 了 一 个 

















完整 的 参数 列表 ， 最 终生 成 排 重 的 缓存 索引 。 








在 查询 获取 结果 之 后 ， 返 回 结果 之 前 ， 我 们 将 结果 写 入 了 缓存 之 中 ， 一 个 完整 的 查询 接口 就 这 样 完 成 了 。 


2. 获 取 频 道 详情 


代码 如 下 所 示 : 








// 获取 频道 详情 

app.route.get ('/channels/:id', async req => { 
let id = req.params.id 
let key = 'channel ' + id 


if (app.custom.cache.has (key)) { 
return app.custom.cache.get (key) 
} 
let channel = await app.model.Channel.findone({ 
condition: { id: id } 
4 
if (!channel) throw new Error('Channel not found') 
if (channel.reports >= 3) throw new Error('Channel was banned') 
let account = await app.model.Account.findone ({ 
condition: { address: channel .creatorId } 
}) 
if (account) { 
channel.nickname = account .strl 
} 
let result = { channel: channel } 
app.custom.cache.set (key, result) 
return result 


Ea 



































频道 详情 的 查询 接口 与 查询 频道 列表 的 接口 类 似 ， 只 是 把 findAll 接 口 换 成 了 findOne， 与 频道 列表 查询 一 样 限制 了 reports 数 量 为 3 的 查询 展示 ， 完 成 了 举报 内 容 的 逻辑 删除 。 最 后 也 对 相关 的 数据 进行 











了 组 装 ， 满 足 前 端 展示 的 需要 。 


11.2.2 ”文章 接口 


文章 的 查询 也 分 为 文章 列表 与 详情 两 部 分 ， 下 面 分 别 介绍 。 


1. 文 章 列表 查询 











在 业务 需求 中 ， 文 章 排序 的 策略 与 频道 略 有 不 同 ， 有 两 种 排序 策略 : 一 种 按 热度 排序 ， 另 一 种 按时 间 排序 ， 两 种 策略 提供 不 同 的 排序 算法 。 针 对 不 同 排序 ， 接 口 提 供 了 两 种 排序 实现 : 


getArticlesByTime 与 getArticlesByScore。 


代码 如 下 所 示 : 





app.route.get ('/articles', async req => { 
let query = req.query 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


let res = null 
if (query.sortBy === 'timestamp') { 
res = await getArticlesByTime (query) 
} else if (query.sortBy === 'score') { 
res = await getArticlesByScore (query) 
} else { 
throw new Error('Sort field not supported') 
* 
await setUsername (res.articles) 
await setChannelName (res.articles) 
app.custom.cache.set (key, res) 
return res 





























按时 间 排 序 算法 实现 方式 与 普通 的 排序 并 没有 什么 不 同 ， 这 里 为 了 提高 代码 可 读 性 与 可 维护 性 ， 把 业务 逻辑 与 按照 分 数 排序 算法 一 同 抽 离 成 单独 函数 进行 调用 ， 这 里 我 们 重点 看 时 间 排 序 。 热 门 文章 的 
分 数 计算 是 通过 打 赏 金额 与 时 效 性 进行 评分 ， 打 赏 数量 越 高 ， 分 数 高 ， 发 布 时 间 越 新 评分 也 就 越 高 ， 但 就 打 赏 额 和 时 间 所 占 的 权重 相 比 ， 时 间 占 比 最 大 ， 也 就 是 说 ， 打 赏 数量 相同 的 情况 下 ， 较 新 的 文章 , 


得 分 较 高 。 代 码 如 下 所 示 : 




















// 通过 文章 得 分 排序 
async function getArticlesByScore (options) { 
Jet condition = { 
reports: { $lt: 3 } 


} 
// 条 件 过 滤 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


let latestArticles = await app.model .Article.findAll ({ 
condition: condition, 
limit: 300, 
sort: { timestamp: -1 } 

}) 

let popularArticles = await app.model.Article.findAll ({ 


limit: 300, 

sort: { votes: -1 } 
}) 
// 排 重 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


allArticles.forEach(a => { 
a.score = calcScore (a) 

}) 

allArticles.sort((l, r) => { 
return r.score - 1.score 


}) 


return { articles: allArticles.slice(0, options.limit || 50) } 


} 
// 得 分 算法 


function calcScore (article) 


{ 
// 据 目前 时 间 计算 出 文章 已 经 发 布 多 少 小 时 


let elapsedHours = (Date.now() - app.getRealTime (article.timestamp)) / 3600000 


return Math.sqrt (article.votes + 1) / Math.pow(elapsedHours + 2, 1.8) 
} 








option 参 数 是 query 对 象 ， 我 们 在 通过 分 数 排序 之 前 ， 需 要 先 获 得 最 新 的 一 批文 章 与 分 数 最 高 的 一 批文 章 ， 将 其 排 重 处 理 后 ， 通 过 分 数 算法 进行 排序 ， 得 出 的 结果 就 是 最 终 展示 的 效果 。 





calcScore 莉 数 保证 了 整个 排序 算法 能 够 按照 时 间 与 打 赏 额 数量 进行 排序 ， 展 示 热门 文章 ， 
Oi 
文章 详情 与 频道 详情 实现 相似 ， 不 再 的 述 。 


2.: 文 章 评论 列表 


























我 们 都 知道 ， 文 章 的 评论 有 回复 的 功能 (/articles/: id/comments) ， 查 询 评论 的 同时 也 

















展示 对 评论 的 回 


复 ， 如 果 一 条 评论 是 回复 另 一 条 评论 的 ， 我 们 需要 知道 这 条 评论 是 来 自 于 哪 位 用 户 ， 这 就 























需要 进行 二 次 查询 ， 这 里 我 们 通过 过 滤 的 方式 ， 同 时 查询 出 所 有 拥有 pid 属 性 并 与 之 对 应 的 评论 数据 ， 排 重 后 为 其 对 应 的 authorld 填 充 昵 称 。 代 码 如 下 所 示 : 








app.route.get ('/articles/:id/comments', async req => { 


// 封装 条 件 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


let comments = await app.model.Comment.findAll ({ 


condition: [{ aid: id }, { reports: { $lt: 3 } }], 
limit: req.query.limit || 50, 
offset: req.query.offset || 0, 
sort: sort 
}) 
let replyIds = [] 
for (let c of comments) { 
if (c.pid) replyIds.push(c.pid) 
* 
let replyComments = await app.model.Comment.fingdAll ({ 
condition: { 
id: { $in: replyIds } 
] 7 
fields: ["authorId'，'"id'] 


// 排 重 作者 信息 并 缓存 

let replyAuthorMap = new Map () 

for (let rc of replyComments) { 
replyAuthorMap.set (rc.id, rc.authorId) 

» 


// 统一 查询 
let addresses = comments.map(c => c.authorId) .concat (replyComments .map (rc 
=> rc.authorId)) 
let accounts = await app.model.Account.findAll ({ 
condition: { 
address: { $in: addresses } 
}, 
fields: ['strl', 'address'] 
}) 


// 名 称 赋值 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 
let result = { comments: comments, count: count } 加 

app.custom.cache.set (key, result) 

return result 
































代码 中 使 用 findAll 给 定 参数 对 象 中 ， 用 fields 指 定 查询 实体 的 返回 属性 ，str1 就 是 侧 链 中 对 应 的 用 户 昵称 字段 。 而 查询 条 件 字段 中 指定 地 址 条 件 的 {$in: addresses} 值 ， 就 是 实现 了 SQL 语句 中 in 的 查询 
效果 。 














11.2.3 “投票 接口 





查询 投票 记录 、 查 询 投票 详细 信息 与 查询 频道 的 思路 一 致 ， 不 再 详细 解释 。 








由 | 


前 面 也 解释 了 Vote 的 储存 罗 辑 ， 在 抽奖 模式 下 Vote 作 为 一 种 累计 数据 模式 ， 详 细 的 打 迷 数据 则 存储 在 bid 表 中 ， 而 在 默认 模式 下 为 记录 模式 ， 
Oi 


查询 抽奖 记录 与 其 他 列表 查询 接口 实现 相同 ， 不 再 详 述 。 


E 复 打 赏 不 再 累加 ， 而 是 创建 新 的 Vote 记 录 。 


控制 内 容 查询 过 滤 逻 辑 


























/access 接 口 是 在 实际 的 前 端 使 用 过 程 中 添加 的 ， 主 要 为 了 满足 在 前 端 进行 页 面 跳 转 时 ， 判 断 当前 的 投票 记录 所 对 应 的 文章 是 否 被 举报 超过 三 次 ， 或 者 在 点 击 文章 的 同时 查询 当前 的 文章 所 在 频道 是 否 被 
举报 超过 三 次 。 代 码 如 下 所 示 : 











// 获取 打开 权限 
app.route.get ('/access', async req => { 
let { id, type } = req.query 
if (type == 2) { // article 
let article = await app.model .Article.findone ({ 
condition: { id: id } 
1) 
if (!article) throw new Error('Article not found') 
if (article.reports >= 3) { 
return { errorType: 2, access: false } 
} else { 
let channel = await await app.model.Channel.findone ({ 
condition: { id: article.cid } 
}) 
if (channel.reports >= 3) return { errorType: 1, access: false } 
} 
return { access: true } 
} else if (type =— 3) { // vote 
let vote = await app.model .Vote.findone({ 
wonditienm t dev- Lid-} 
i) 


if (!vote) throw new Error('Vote not found') 





let article = await app.model .Article.findone ({ 
condition: { id: vote.aid, reports: { $1lt: 3 } } 
}) 
if (!article) throw new Error('Article not found') 
if (article.reports >= 3) { 
return { errorType: 2, access: false } 
} else { 
let channel = await await app.model.Channel .findone({ 
condition: { id: article.cid } 
}) 
if (channel.reports >= 3) return { errorType: 1, access: false } 
} 


return { access: true } 


DD 





参数 说 明 如 下 。 
“id: 需要 检验 的 数据 id。 


“ type: 数据 类 型 ，1 为 channel，2 为 article，3 为 vote。 











这 里 与 report 合 约 的 处 理 思路 相同 ， 同 一 个 接口 处 理 不 同 实体 的 判断 逻辑 ， 目 前 只 需要 依据 需求 处 理 vote 与 article 即 可 ， 通 过 传递 查询 获取 上 级 数据 是 否 被 禁用 。 
























































返回 数据 包含 两 个 字段 ，access 返 回 boolean 类 型 的 值 ， 代 表 索 要 查询 的 数据 是 否 具 有 权限 ; errorType 与 参数 规则 相同 。 这 样 ， 我 们 就 可 以 通过 access 接 口 查 询 数 据 是 否 可 以 访问 。 














到 这 里 ， 我 们 已 经 完成 了 写 入 合约 和 查询 接口 的 编写 ， 后 端的 工作 是 否 就 算 结束 了 呢 ? 当然 没有 ， 我 们 还 缺少 了 测试 环节 ， 下 一 章 我 们 将 会 编写 测试 代码 。 





11.3 ”DApp 的 前 端 实现 





























都 采 





合约 和 查询 数据 。 查 询 和 合约 调 





这 一 部 分 我 们 简要 介绍 如 何在 前 端 与 DApp 交 互 ， 在 浏览 器 环境 调 






































发 起 交易 的 工具 通过 私 钥 签名 参数 传递 给 应 


























交互 将 会 





到 之 前 提 到 的 asch-js 库 ， 作 为 前 端 向 应 








前 端 与 应 








113.1 登录 














这 里 所 说 的 登录 ， 其 实 是 账户 余额 查询 ， 这 里 只 需要 传 入 地 址 作为 参数 中 
有 人 都 能 通过 一 个 地 址 查询 账户 的 余额 ， 这 也 是 遵循 区 块 链 的 公开 透明 的 原则 。 
























































就 默认 他 具有 此 账户 的 控制 权 。 但 是 在 实现 的 过 程 中 还 是 需要 
了 通用 的 查询 接口 进行 账户 查询 而 已 。 





所 以 前 端 只 要 能 够 通过 用 户 登录 的 行为 ， 查 询 到 用 户 的 余额 信息 ， 户 输入 秘 钥 ， 


行 查询 。 可 以 理解 为 我 们 把 对 权限 的 校 验 放 在 了 客户 端 进行 ， 只 是 使 





























了 RESTful 请 求 的 方式 ， 所 以 不 管 是 在 HTML 5 还 是 命令 








行 ， 都 可 以 与 应 

















交互 。 
































然后 使 


服务 器 ， 那 么 读 操作 就 和 普通 的 Web 接 口 请 求 相 同 ， 下 面 我 们 简单 说 明 如 何在 前 端 调用 接 


可 ， 与 我 们 对 登录 的 理解 不 同 ， 这 里 的 登录 只 是 一 个 GET 请 求 ， 通 过 地 址 查询 账户 余额 ， 而 这 个 接口 也 是 对 全 网 开放 的 ， 即 所 


asch-js 计 算出 公 铜 ， 再 通过 公 钥 计算 出 地 址 进 





import { getPub, getAddr } from 'http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/../utils/asch' 


// getPub 
// getAddr -> RschJs.crypto.getRdqress (publickey) 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 


-> AschyJs.crypto.getKeys (secret) .publicKey 


login() { 

this. $v.secret.$touch () 

if (this.$v.secret.$error) { 
return null 

} else { 
let account = {} 
account .secret = this.secret 
account .publicKey = getPub (this.secret) // 通过 私 钥 计 算出 公 钥 
account.address = getAddr (account.publicKey) // 通过 公 钥 计算 出 地 址 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 





整个 过 程 也 是 为 了 保证 数据 安全 性 ， 让 私 钥 在 本 地 验证 的 方式 避免 敏感 信息 通过 网 络 传输 。 


11.3.2 ”调用 合约 
































户 的 私 钥 只 允许 在 本 地 使 




















上 节 提 到 ， 在 调 





合约 时 将 参数 通过 asch-js 签 名 后 可 以 提高 交易 的 安全 性 ， 前 端 依然 要 遵循 此 类 原则 


， 避 免 使 











网 络 明文 传输 私 钥 。 举 个 例子 : 





// 本 地 签名 API 
export const callContractsApi = (options, secret) => 
AschJs .DApp.createInnerTransaction (options, secret) 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/O0EBPS/Text/... 
// 震 用 合约 加 
api.callContractsApi = trans => { 


return fetch(urls.callContractsApi, { transaction: trans }, 'put') // fetch 


封装 了 请 求 接口 
} 
// 请 求 创建 频道 合约 
api.createChannel = (channel, secret) => { 
let trans = createInnerTransaction( 
{ 
fee: '1000000000000'， // 手续 费 
type: 1005, // 合约 类 型 
args: [channel.name, channel.url, channel.desc] // 参数 


}, 
secret // 账户 秘 钥 


return api.callContractsApi (trans) 


} 














这 里 做 了 合约 调 
的 签名 代替 私 钥 本 身 。 





11.3.3 ”调用 接口 






































调用 接口 通过 API 传 递 参数 ， 用 url query 的 形式 传递 参数 ， 这 里 提 到 的 所 有 查询 都 不 做 权限 的 限制 ， 只 是 数据 更 新 后 包含 10 秒 钟 的 确认 。 
那么 为 了 保证 用 户 体验 ， 在 前 端 需要 有 定时 刷新 ， 每 隔 10 秒 刷新 一 下 服务 器 数据 ， 始 终 显示 最 新 的 数据 。 


















































MVVM 前 端 架构 ， 结 合 状态 管理 工具 ， 通 过 数据 驱动 视图 






































当然 如 果 碰 到 比较 复杂 的 应 用 ， 前 端 要 提供 局 部 更 新 Ul 或 数据 的 方式 ， 这 里 推荐 使 有 





114 本章 总 结 











经 过 本 章 的 学 习 ， 读 者 可 能 会 发 现在 阿 希 链 上 开发 一 个 DApp 的 过 程 和 开发 传统 的 Web 应 用 非常 类 似 。 从 传统 的 Web 开 发 切换 到 基于 阿 希 链 开发 DApp 是 一 件 非常 容易 的 


第 12 章 “DApp 测 斌 














前 面 的 章节 我 们 从 环境 搭建 ， 应 
接口 进行 测试 。 

















的 本 地 签名 ，createlnnerTransaction 封 装 了 asch-js 中 的 签名 函数 AschJs.DApp.createlnnerTransaction 通 过 私 钥 将 参数 签名 ， 得 出 的 结果 在 测试 章节 中 有 分 析 ， 签 名 函数 


无 颖 更 新 。 





a 











计 

















设计 ， 代 码 实 现 三 个 部 分 完成 了 DApp 开 发 的 整体 流程 ， 不 过 我 们 还 缺少 了 很 重要 的 一 环 就 是 测试 。 这 一 章 我 们 从 抽奖 合约 的 整个 测试 流程 代码 来 讲解 如 何 对 合约 与 


12.1 测试 准备 
































首先 我 们 来 看 一 下 项 目 中 ，test 目 录 中 文件 结构 ，lib 目 录 中 存放 了 方便 测试 调用 的 封装 函数 ， 以 base 命 名 ， 而 test 根 目录 的 cctime 文 件 包含 了 主要 的 测试 用 例 。 












































编写 测试 用 例 之 前 ， 我 们 先 熟 悉 一 下 base 文 件 中 的 函数 ， 这 些 函 数 作为 测试 工具 提供 给 测试 用 例 调用 ， 封 装 了 合约 和 访问 接口 代码 。 
































12.1.1 初始 化 函数 























编写 测试 用 例 之 前 ， 需 要 将 常用 的 方法 抽 离 封装 ， 放 入 base 文 件 中 ， 这 里 我 们 使 用 supertest 和 chai 作 为 主要 的 测试 框架 ， 大 家 可 以 在 源码 文件 中 找到 测试 文件 中 的 声明 。 以 下 是 初始 化 相关 的 函数 : 






































// 合约 调用 的 封装 函数 ， 返 回 promise 对 象 
function PIFY (fn, receiver) { 
return (http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/...args) => { 
return new Promisel( (resolve, reject) => { 
fn.apply (receiver, [ 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/...args, 
(err, result) => { 
return err ? reject (err) : resolve (result) 


// 调用 主 链接 口 的 封装 函数 
function baseApiGet (path, cb) { 
baseApi 
.get (path) 
.expect ('Content-Type', /json/) 
.expect (200) 
.end (function (err, res) { 
cblerr, res && res.body) 
}) 
} 


// 调用 DAPP 接口 封装 函数 
function dappApiGet (path, cb) { 
let seperator = path.indexOf('?') !== -1 ? '&' : '?' 
dappApi 
.get (path + seperator + ' t=' + new Date () .getTime()) 
.expect ('Content-Type', /json/) 
.expect (200) 
.end (function(err, res) { 
debug ('dappApiGet response err: $j, res: 
cblerr, res && res.body) 


}) 


/ err, res.body) 


} 
// 初始 化 方法 


function init(cb) { 
baseApiGet ('/dapps?name=asch-dapp-cctime-test', function(err, res) { 

debug ('init find dapp err: %j, res: ', err, res) 
if (err) return cb('Request error: ' + err) 
if (!res.success) return cbl('Server error: ' + err) 
if (!res.dapps.length) return cb('DApp not found') 
dapp = res.dapps{[0] 
id = dapp.transactionId 
dappUrl = baseUrl + '/api/dapps/' + id 
GappApi = supertest (dappUr]1) 
cb () 


























我 们 看 init 方 法 中 ， 对 DApp 的 id 进行 了 查询 ， 根 据 应 用 的 名 称 从 主 链 动态 获取 当前 侧 链 应 用 的 ID， 为 后 续 测试 接口 的 调用 初始 化 Dappld 数 据 。 






































接 下 来 我 们 看 一 下 测试 常用 的 工具 函数 。 





12.1.2 ”区 块 等 待 























在 发 起 一 笔 交 易 之 后 ， 需 要 等 待 交 易 确认 之 后 再 执行 下 一 步 的 操作 ， 调 用 sleep 函 数 进行 等 待 ， 之 后 继续 执行 。 这 个 函数 在 测试 流程 中 会 多 次 使 用 ， 因 为 10 秒 一 个 区 块 的 特性 ， 很 多 的 操作 需要 在 区 块 确 
认 之 后 获得 验证 ， 不 仅 是 写 操作 ， 读 取 的 接口 依然 需要 在 上 一 次 写 操作 之 后 等 待 区 块 确认 才能 获取 到 最 新 数据 。 区 块 等 待 相 关 函 数 如 下 所 示 : 
































// 等 待 函数 
function sleep(n, cb) { 
setTimeout (cb, n) 


bE: 
// 区 块 等 待 函数 


async function onNewBlockAsync() { 
let firstHeight = await PIFY (getHeight) () 
while (true) { 
await PIFY (sleep) (1000) 
let height = await PIFY (getHeight) () 
if (height > firstHeight) break 
} 
} 





12.1.3 ”账户 生成 与 转账 


生成 随机 账户 与 转账 接口 也 需要 测试 ， 我 们 留意 到 了 在 base 文 件 头 部 定义 了 创 世 账 户 的 地 址 和 秘 钥 ， 创 世 账 户 可 以 通过 asch-js 中 的 合约 接口 向 新 生成 的 账户 转账 ， 随 机 账户 有 了 余额 就 能 够 继续 调用 应 
中 的 自 定义 合约 ， 进 行 合 约 相关 的 功能 测试 。 账 户 及 转账 相关 的 函数 如 下 : 























// 生成 随机 秘 钥 
function randomSecret() { 
return Math.random() 
.tostring (36) 
.substring (7) 
} 


// 获取 随机 账户 ， 包 括 地 址 ， 公 钥 
function getRandomAccount (memo=false) { 
Var secret = memo || randomSecret () 


Var keys = AschJS.crypto.getKeys (secret) 
return { 
address: AschJS.crypto.getAddress (keys.publicKey), 
PublicKey: keys.publicKey, 
secret: secret 
} 
} 


// 转账 接口 封装 
function giveMoney (address, currency, amount, cb) { 
dappApi 
.put ('/transactions/unsigned') 
.Set ('Accept', 'application/json') 
.Send ({ 
secret: genesisAccount.secret, 
fee: '10000000', 
type: 3, 
args: JSON.stringify([currency, amount, address]) 
}) 
.expect ('Content-Type', /json/) 
.expect (200) 
.end (function (err, res) { 
debug ('giveMoney res err: %j, res: 
assert (!err) 
assert (res.body.success) 
cbl(err, res) 


}) 


', err, res.body) 


} 
// 转账 后 等 待 区 块 确认 


async function giveMoneyAndWaitAsync (addresses, currency, amount) { 
for (let i = 0; i < addresses.length; i++) { 
await PIFY (giveMoney) (addresses[i], currency, amount || randomCoin()) 
} 
await onNewBlockAsync () 


} 





1. 随 机 账户 








randomSecret 调 用 randomSecret 生 成 随机 字符 串 作 为 账户 秘 钥 ， 我 们 可 以 看 到 AschJS.crypto.getKeys 函 数 能 够 将 字符 串 格 式 的 秘 钥 通过 非 对 称 加 密 得 出 一 个 包含 公 钥 和 私 钥 的 秘 钥 
对 ，AschJs.crypto.getAddress 通 过 公 钥 算出 账户 的 地 址 。 























randomsSecret 返 回 的 是 一 个 随机 生成 但 被 截取 之 后 的 字符 串 。 通 常情 况 下 ，Asch 只 支持 符合 BlIP39 规 范 的 密 钥 字符 ， 也 就 是 我 们 熟悉 的 “ 助 记 词 ”格式 的 密码 ， 但 这 里 为 了 测试 方便 ， 直 接 使 用 随机 的 
七 位 字符 串 ， 同 样 可 以 算出 符合 规则 的 公 铜 ， 也 能 计算 出 地 址 。 当 然 ， 随 机 账户 也 支持 通过 指定 助 记 词 的 方式 获取 公 钥 与 地 址 。 





























2. 转 网 
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转账 在 DApp 以 类 型 2 的 合约 实现 ， 所 以 这 里 的 转账 就 是 在 调用 DApp 内 部 的 合约 ， 我 们 可 以 在 giveMoney 函 数 中 看 到 合约 调用 的 格式 。 























合约 参数 结构 如 下 : 
“secret 为 合约 调用 者 的 秘 钥 ，String 类 型 。 
“ fee 为 合约 调用 手续 费 ，bigNumber 类 型 。 
“ type 为 合约 类 型 ，Number 类 型 ， 与 自 定义 合约 数据 对 应 。 
“ atgs 为 合约 参数 ，Array 类 型 。 
Bt 


我 们 看 到 giveMoney 调 用 合约 时 请 求 了 /transactions/unsigned 接 口 ， 这 个 接口 可 以 接受 未 签名 的 参数 和 密 钥 执 行 合约 ， 这 样 做 在 测试 环境 虽然 没有 问题 ， 但 是 在 正式 的 生产 环境 中 会 有 很 大 的 风险 ， 我 们 的 
私 钥 内 容 会 有 被 网 络 劫持 的 风险 ， 所 以 在 调用 合约 时 ， 尽 可 能 避免 通过 网 络 传输 自己 的 密 钥 ， 而 是 用 本 地 签名 的 方式 加 密 参 数 ， 然 后 请 求 /transactions/signed， 这 点 一 定 要 十 分 注意 。 


相关 代码 如 下 : 





// 用 签名 的 方式 调用 内 置 合约 
function submitInnerTransaction(trs, cb) { 
debug('submitInnerTransaction input: ', trs) 
dappApi 
.Put('/transactions/signed') 
.set ('Accept', 'application/json') 
.send({ 
transaction: trs 
计 
.expect ('Content-Type', /json/) 
.expect (200) 
.end (function (err, res) { 
debug ('submitInnerTransaction response err: $j, res: $j', err, res.body) 
cblerr, res.body) 
































上 面 的 代码 通过 接收 签名 参数 调用 合约 的 接口 ， 这 个 函数 发 送 了 命名 为 transaction 的 参数 ，trs 是 用 asch-js 前 端 JavaScript 工 具 库 进行 签名 返回 的 transaction 对 象 。 我 们 来 看 一 个 例子 : 
































// 调用 发 布 文章 合约 
async function postArticleAsync (article, secret) { 
let trs = AschJS.dapp.createInnerTransaction( 

{ 

fee: '10000000', 

type: 1000, 

args: [ 
article.title, 
article.url, 
article.text, 
article.tags, 
article.cid 
article.settleHeight 

] 


}, 
secret // 只 用 做 签名 使 用 ， 不 参与 网 络 传输 
) 
return await PIFY (submitInnerTransaction) (trs) 


} 




















使 用 AschjJs.dapp.createlnnerTransaction 将 合约 参数 通过 秘 铀 secret 签 名 之 后 传 入 submitlnnerTransaction 函 数 ， 完 成 合约 调用 。 与 上 面 gjveMoney 函 数 不 同 的 是 ，createlnnerTransaction 返 回 的 
是 通过 秘 钥 签名 的 内 容 ， 将 签名 后 的 数据 通过 网 络 发 送 ， 这 样 提 高 了 整个 传输 过 程 秘 钥 的 安全 性 。 














我 们 来 看 签名 后 的 transaction 参 数 是 什么 样子 : 





"transaction": { 


"fee": "10000000", 
"timestamp": 58261151, 
"senderPublicKey": "8065a105c785a08757727fdedq3a06f8f312e73ad40f1f3502 
e0232ea42e67efd", 
: 1000, 


"[" 测 试 合约 参数 内 容 ","", "## 这 是 一 篇 测试 内 容 \n\n 作 为 测试 参数 使 用 的 
'12",445964]", 
"signature" : 
670697eqa26bcbldf625ec7a74bb0054dlfad0ebefcldclc04f4916f44dd59f87a 
1lead205" 





"8657684e3694b000fae2d2473f7c03efcee8f61462498f924ac38e2 














与 上 面 未 签名 调 
于 后 端 接口 对 参数 验证 。 








转账 接口 的 参数 对 比 ， 本 地 签名 后 得 出 的 参数 中 少 了 secret 属 性 ， 多 了 signature 属 性 ， 而 这 个 





属性 把 通过 sha256 算 法 得 出 的 私 钥 与 整个 transaction 参 数 经 过 哈 希 计算 之 后 得 出 ， 用 
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12.2 合约 流程 测试 




















我 们 现在 开始 以 一 个 发 布 文章 、 





户 打 赏 、 结 算 抽奖 和 














户 领 奖 整个 应 用 的 核心 流程 进行 测试 ， 


相关 代码 如 下 : 


其 他 的 合约 调用 基本 上 都 按照 发 布 文章 合约 的 结构 组 织 参 数 ， 完 成 合约 调用 的 封装 。 这 样 ， 我 们 就 可 以 着 手 编写 测试 了 。 











// 初始 化 测试 变量 
describe('cctime', () => { 
before (async function() { 
await base.initAsync() 


}) 


// 获取 频道 列表 

it('should be ok to get all channels', async function() { 
let m = await base.dappApiGetAsync('/channels') 
debug('get all channels', m) 
assert (m.success, 'get seccess') 
assert .exists (m.count, "get count') 
assert.isArray (m.channels, "get result') 


















































首先 ， 在 测试 用 例 before 函 数 中 初始 化 测试 变量 、DApp 数 据 和 创始 账户 信息 作为 后 续 测试 函数 的 基础 ， 然 后 执行 获取 频道 列表 的 测试 用 例 。 我 们 使 用 await base.dappApiGetAsync ('/channels') 

















请 求 一 个 AP1， 获 取 到 频道 列表 信息 ， 并 用 断言 库 校 验 结果 。 











下 面 我 们 对 核心 的 业务 流程 进行 测试 ， 测 试 的 思路 如 下 : 





创建 频道 。 
2) 初始 化 账户 。 


3) 在 频道 里 创建 包含 抽奖 模式 的 文章 。 














4) 模拟 三 个 用 户 各 打 赏 两 笔 。 


5) 文章 结算 。 








6) 获奖 用 户 领 奖 。 











| 


检查 各 自 账户 的 余额 。 
核心 业务 流程 的 代码 如 下 : 


// 测试 核心 业务 流程 
describe('test core flow', () => { 
let channelTransactionId, channelId 
before (async function() { 
let delegateAccount = base.getRandomAccount (delegateSecrets[0]) 
await base.giveMoneyAndWaitAsync([delegateAccount.address], 'CCTime. 
XCT', '1050000000000') 
let res = await base.createChannelAsync( 
{ 
name: 'test channel ' + Math.random(), 
desc: 'this is a channel desc in case to pass the validate of 50 
chars ok that is not long enough give you 50 ', 
url: 'http://openmindclub.qiniudn.com/caos/caos.jpg’ 
}, 
delegateSecrets[0] 
) 
debug('post channel', res) 
channelTransactionId = res.transactionId 
assert (res.success) 
assert (res.transactionId.length === 64) 
await base.onNewBlockAsync () 
1) 


it('test channel get', async function() { 

let res = await base.dappApiGetAsync('/channels?tid=' + 
channelTransactionId) 

assert (res.success) 

assert (res.count === 1) 

assert.isArray (res.channels) 

assert (res.channels.1length = 

assert (res.channels[0] .tid 

channelId = res.channels[0] .id 


计 


1) 
channelTransactionId) 





// 频道 变更 花费 50000000000 token 


}) 


Ye //www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 





























上 面 的 代码 使 用 受托 人 创建 了 一 个 新 频道 ， 并 通过 频道 查询 接口 通过 交易 ID 获取 到 了 频道 的 ID， 完 成 了 基本 的 测试 逻辑 ， 同 时 保存 了 channelld 作 为 后 续 创建 文章 的 数据 。 


Bt 总 


await base.onNewBlockAsync () 是 在 等 待 区 块 确认 之 后 再 继续 执行 。 我 们 看 到 最 初 先 给 账户 转 入 10500 的 Token， 用 于 创建 频道 和 更 新 频道 的 消耗 。 


打 赏 文章 测试 代码 如 下 : 





// ”测试 打 赏 文章 流程 
it('settle article test', async function() { 
let authorAccount = base.getRandomAccount () 
let userl = base.getRandomAccount () 
let user2 = base.getRandomAccount () 
let user3 = base.getRandomAccount () 
let addresses = [userl.address, user2.address, user3.address] 
await base.giveMoneyAndWaitAsync (addresses, 'CCTime.XCT', '520000000') 
await base.giveMoneyAndWaitAsync([authorAccount.address], 'CCTime.XcCT', 
'20000000') 
await base.onNewBlockAsync () 
// 获取 应 用 区 块 高 度 
let res = await base.dappApiGetAsync('/blocks/height') 
assert (res.success) 
let currentHeight = res.height 
// 发 布 文章 
res = await base.postArticleAsync( 
{ 
title: 'settle article title', 


rl 和 

text: 'first settle article desc with chars Show it if is greater 
than 50 ', 

tags: '', 


cid: channelId, 
awardType: 1, 
settleHeight: currentHeight + 2 
}, 
authorAccount .secret 
) 
assert (res.success) 
assert (res.transactionId.length === 64) 
let articleTransactionId = res.transactionId 
await base.onNewBlockAsync () 




















在 上 面 代码 中 ， 首 先进 行 账户 的 初始 化 ， 生 成 了 四 个 账户 ， 一 个 账户 负责 创建 文章 和 结算 奖励 ， 另 外 三 个 作为 打 赏 用 户 。 然 后 对 创建 的 文章 执行 两 次 打 赏 为 了 验证 方便 ， 新 创建 的 账户 两 次 打 赏 的 总 
额 为 5 个 Token， 创 建文 章 的 账户 拥有 0.2 个 Token， 操 作 之 后 扣 掉 手续 费 保证 在 结算 之 前 账户 余额 都 是 零 ， 方 便 验 证 。 












































另外 ， 我 们 为 了 测试 需要 ， 将 后 端 关于 区 块 高 度 的 限制 暂时 去 掉 ， 并 设置 结算 区 块 高 度 为 当前 的 高 度 加 2， 这 样 ， 在 用 户 投票 之 后 直接 执行 结算 。 
Oi 


试 代码 中 ， 创 建 频道 或 文章 之 后 ， 因 为 需要 区 块 确认 ， 所 以 我 们 没有 办 法 立即 获取 到 数据 的 ID， 只 能 先 拿 到 transactionId， 待 区 块 打包 之 后 ， 再 通过 查询 接口 用 tid 获 取 实 际 的 数据 ID， 再 进行 下 一 步 的 
操作 ， 测 试 文件 中 ， 会 出 现 很 多 这 样 的 处 理 ， 这 也 是 区 块 特性 所 决定 的 。 














荡 














户 打 赏 测试 代码 如 下 : 











// 用 户 打 赏 
debug('vote article 3 users') 
res = await base.voteArticleAsync ({ aid: articleId，amount: '250000000' }, 
userl .secret) 
assert (res.success) 
assert (res.transactionId.length === 64) 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 
await base.onNewBlockAsync () 
debug ('check vote num ') 


res = await base.dappApiGetAsync('/votes?aid=' + articleId) 
assert (res.success) 

assert (res.count === 3) 

assert .isArray (res.votes) 

let vote = res.votes[1] 


assert (vote.type 一 = 1) 
assert (vote.awardState === 1) 
assert (vote.amount === '500000000') 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 

















上 面 代码 中 ， 用 另外 三 个 账户 对 文章 进行 了 打 赏 ， 每 个 账户 打 赏 两 次 不 同 的 金额 ,但 总 额 是 5 XCT， 所 以 最 终 文章 的 抽奖 池 中 ， 应 该 是 15 个 XCT， 结 算 结果 根据 15 XCT 的 总 额 进行 验证 ， 然 后 验证 文章 
投票 额 与 投票 者 的 余额 是 否 正确 ， 代 码 如 下 : 














debug('calc settle prize') 

// 奖励 结算 

res = await base.calculatePrizeAsync (articlelId, authorAccount.secret) 
assert (res.success) 

assert (res.transactionId.length === 64) 

await base.onNewBlockAsync () 


debug('check calc article state') 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/18464/0EBPS/Text/... 
debug('check calc article reward') 


res = await base.dappApiGetAsync('/accounts/' + authorAccount.address) 
assert (res.success) 

assert.isObject (res.account) 

balance = res.account.balances[0] .balance 

assert (balance === '450000000') 








合约 中 对 抽奖 模式 的 结算 规则 是 受托 人 10%， 作 者 30%， 获 奖 者 60%， 因 为 受托 人 的 奖励 是 平均 分 给 三 个 账户 ， 所 以 验证 不 是 那么 方便 ， 不 过 我 们 只 要 验证 作者 和 获奖 者 的 奖励 额 就 能 确定 结算 是 否 正 
确 ， 那 么 最 终 的 结果 是 作者 获得 4.5 个 XCT， 抽 奖 人 获得 9 个 XCT。 





验证 奖励 测试 代码 如 下 : 





debug('check calc vote reward ') 


res = await base.dappApiGetAsync ('/votes?aid=' + articleId) 

assert (res.success) 

assert (res.count === 3) 

assert.isArray (res.votes) 

// 获得 最 终 得 奖 的 投票 

let votes = res.votes.filter( => { 
return v.settleAmount > 0 

}) 

assert (votes.length === 1) 

vote = votes[0] 

let winnerId = vote.voterId 

assert (vote.amount === '500000000') 

assert (vote.settleAmount === '900000000') 


debug ('account get prize ') 

// 获得 获奖 者 的 秘 钥 

let winnerSecret = utils.getWinnerSecret ([userl, user2, user3], winnerId) 
res = await base.getRewardAsync (vote.id, winnerSecret) 

assert (res.success) 


assert (res.transactionId.length = 64) 





await base.onNewBlockAsync () 
debug('check winner balance') 


res = await base.dappApiGetAsync('/accounts/' + winnerId) 
assert (res.success) 

assert.isObject (res.account) 

balance = res.account.balances[0] .balance 

assert (balance === '900000000') 























最 终 ， 在 根 目录 执行 npm test， 等 测试 运行 结束 ， 就 能 看 到 应 用 测试 执行 的 结果 了 。 


12.3 ”本 章 总 结 














我 们 已 经 把 一 个 DApp 服 务 的 所 有 开发 环节 阐述 了 一 遍 ， 上 述 提 及 的 测试 代码 也 只 是 完成 了 核心 功能 验证 ， 并 没有 完全 覆盖 到 每 一 个 合约 和 操作 场景 ， 如 果 读者 感 兴趣 可 以 尝试 在 笔者 的 基础 上 补充 或 
重 构 ， 也 欢迎 对 项 目 提出 改进 建议 。 





